traits vs value objects

[kjx]

We've often talked about value objects - objects with no mutable state. Do traits create value objects? Can we create value objects any other way?

consider:

object true = {
 inherit boolean
 method prefix! { false }
 method ifTrue(block)ifFalse(_) { block.apply } 
 ...
}

vs

trait true {
 inherit boolean
 method prefix! { false }
 method ifTrue(block)ifFalse(_) { block.apply } 
 ...
}

Do we need an is value annotation which means something like 'doesn't capture any mutable state? If so, can you distinguish multiple instantiations of the same trait - given that traits can have no vars, not even defs, no method code)... How does built equality work with this, though?

[apblack]

Traits can capture state — they just can't have def and vars. So, sometimes multiple instantiations of the same trait can have different behavior.

No, we don't need an is value annotation. Why would we? We can and do have value objects without any such annotation. Equality will work with these objects however the programmer defines equality to work with these objects.

[kjx]

No, we don't need an is value annotation. Why would we?

So programmers can make clear their intention that this is a value object. Newspeak just does this by inheriting from a Value class.

We'd have to decide what a value object was of course: no mutable state, no access to identity comparison would be a start. I think C# amongst others makes this distinction: the point is that implementations could optimise them - notable pass by value and embed into other objects. I guess such as design would be better than C# in that this would be an option layered on top of object semantics, so implementations wouldn't have to do anything special.

On reflection, working out what manifest means, whether we want other annotations like readonly or pure, would be more important. or, you know, a static type system