reflections on value objects

[jonathandavid]

The following article makes an interesting criticism of C# structs:

The Quest for Quick-and-Easy Immutable Value Objects in C#

In short, the author says that .NET's "value type" abstraction is mostly good, but that C# structs are not the best way to put it in practice. He ends by suggesting a mechanism for defining value objects that would work better that structs.

I think Cobra should go this way, i.e., it should forget about C# style structs (therefore the struct keyword should be dropped) and a more powerful mechanism for defining value objects should be considered. Nemerle has the "Record" macro, which could serve as an inspiration too.

Just an idea, I know there are more urgent issues to address now.

[Charles]

I skimmed it and will have to look in more detail later. One of his complaints is this:

"Structs cannot guarantee construction to a valid state. ..."

Regarding the parameterless constructor requirement on a struct, but of course you need this for arrays or you need some special array allocation mechanism where you tell it how to initialize all the elements (which seems problematic). I didn't see him mention that so either he's not aware of that or I missed it.

Also his final example didn't seem that compelling. How much code did he save? A few lines?

[jonathandavid]

Yeah, his examples aren't that spectacular

My main concern with structs is that they seem too tied to the .NET object model (i.e., value semantics, no inheritance, mandatory default constructor, implicit equals/hashCode). What would happen if we use the Java or the D backend instead? Will Cobra try to imitate all this features, so that the Cobra user perceives his struct as behaving the same? Or will we only allow structs to be defined under the .NET backend?

What I meant with my initial post (although I admit that I didn't make it too clear) was that maybe Cobra should have a "back-end independent" definition of what a value type (or struct) is, and that this should be available regardless of the backend. For example, we could say "in Cobra an struct is a type that has readonly fields only, that has automatically generated hashcode and equals implementations, and that cannot inherit or be inherited. Note that I've deliberately omitted any mention to an struct having value semantics, as that would not be implementable in backends other than .NET.

[Charles]

Cobra will simulate the value semantics on other backends, and inherit the value semantics on .NET. The advantage to the value semantics on .NET is one of efficiency. I think .NET can "pack it in" when you have things like an array of 1000 elements of X where X is a struct. That's just one memory blob for the garbage collector to allocate and deal with. Addressing public fields should be faster as well with one less pointer dereference.

If we don't have value semantics for structs then would we simulate Cobra structs with .NET classes? If so, the efficiency is gone.

JVM doesn't even have structs so (a) they have to be simulated and (b) you're not missing out on anything because JVM structs did not exist in the first place. You'll get the semantics due to the Cobra compiler, but not the efficiency--but there's no harm.

There is a good discussion and debate about .NET structs at http://bytes.com/groups/net-c/642610-why-no-struct-inheritance.

My general perception is that .NET made the right decisions about structs. Otherwise if you start relaxing the constraints on them, you just end up with classes which you already had. The Cobra docs will spell out the rules, but anyone familiar with .NET will recognize that the design came from .NET.

D structs don't have inheritance either, probably for the same reasons mentioned in that .NET discussion. I'm guessing D structs will be more efficient than classes, like in .NET.

Regarding immutability, if we add something like that to the language I would not tie it exclusively to structs. Maybe you have a class for which you would like that constraint. It's an independent issue.

In summary, structs are about efficiency. They are conceptually independent of making an immutable object.