Always write a spec, Part Two

re: Always write a spec, Part Two

Limited Atonement — Fri, 09 Sep 2011 16:09:38 GMT

I'm sure you agree that "whitelist programming" (a term from a comment to some other blog that I like, although I can't seem to find it anywhere else) is a bad idea when it can be avoided. Is there any way to get at (things like) this correctly through and through? By "whitelist programming" I mean going through and making a list of cases and programming to all those and hoping (against hope) that you'll get all the cases. This isn't systematic. Is it provable?

Thanks for the post, very informative.

re: Always write a spec, Part Two

Vladimir Reshetnikov — Sat, 28 Nov 2009 19:11:26 GMT

Eric, what about this example?

struct S

{

int X;

static void Main()

{

S[][] s = { };

Foo(ref s[Bar(1)][Bar(2)].X);

}

static int Bar(int x)

{

System.Console.WriteLine(x);

return 0;

}

static void Foo(ref int x) { }

}

Will your implementation print 1 or 1 2 before throwing IndexOutOfRangeException?

re: Always write a spec, Part Two

Vladimir Reshetnikov — Sat, 28 Nov 2009 15:43:03 GMT

Eric, your classification of possible ref/out arguments misses 'this' access in structures.

re: Always write a spec, Part Two

James — Wed, 25 Nov 2009 03:47:21 GMT

"And anyone have any guesses as to why I needed this function implemented?"

IntelliTrace

re: Always write a spec, Part Two

Zak Jensen — Tue, 24 Nov 2009 17:59:43 GMT

@Pop.Catalin

Whoops, that detail escaped me. For some reason, I imagined that the Display() call was the lambda. I'll read closer next time :)

re: Always write a spec, Part Two

Catalin Pop Sever — Tue, 24 Nov 2009 16:31:37 GMT

@Zak Jensen,

I think you've misread the example.

There are "two" calls to Console.WriteLine in a "single" instance method of a immutable value type. The instance method is called only "once", but the output is "two" different values, from within the same instance method that accesses a read only field of the instance.

Basically the instance method reads a field of it's immutable value type instance twice and gets two different values.

Besides, the example can be rewritten without lambdas, by promoting the local immutable value to a field (by using a lambda that captures the variable the compiler does the same thing basically).

re: Always write a spec, Part Two

Zak Jensen — Tue, 24 Nov 2009 14:29:00 GMT

Pop.Catalin said: "P.S. Even Immutable value types aren't thread safe, not just mutable value types".

The immutable value type is still thread safe, the lambda expression is not. From the C#3 specification:

"The body has access to the outer variables (§7.14.4) of the anonymous function. Access of an outer variable will reference the instance of the variable that is active at the time the lambda-expression or anonymous-method-expression is evaluated (§7.14.5)."

i.e. The lambda captures the variable, not it's value.

re: Always write a spec, Part Two

Laura T. — Tue, 24 Nov 2009 12:30:19 GMT

My guess would go for STM, some atomic {} optimization.

re: Always write a spec, Part Two

Catalin Pop Sever — Tue, 24 Nov 2009 11:26:58 GMT

"Once more, mutable value types are revealed to be pure concentrated evil"

You didn't really mean that, did you? :P

Pure evil means absolutely no good can come out of mutable value types (Yes that's and absolute statement) and only bad things.

What I've found is that value types complicate the code allot in multi threading scenarios (in place mutable state), but, I've found value types to be a invaluable tool dozens of times, when there was a performance requirement and resource requirement (memory) above all other requirements (and I mean 2 -3x more computational performance compared to classes, and less than half memory usage).

I can understand why some people don't like value types, but I really and truly love them :)

P.S. Even Immutable value types aren't thread safe, not just mutable value types, http://stackoverflow.com/questions/370859/why-isnan-is-a-static-method-on-the-double-class-instead-of-an-instance-property/370996#370996

re: Always write a spec, Part Two

Michael McMullen — Tue, 24 Nov 2009 02:16:59 GMT

That was one of the other things I was thinking of, but that would also require you to ensure that the method itself does not have any side effects. Most of the other possibilities I thought of also had this restriction, and since ref/out parameters were a major consideration in the spec, it doesn't seem likely that whatever this is for would require the method to have no side effects.