On Tue, Sep 16, 2008 at 6:11 AM, Patrick R. Michaud <[EMAIL PROTECTED]> wrote: > On Mon, Sep 15, 2008 at 10:09:41PM -0500, John M. Dlugosz wrote: >> Darren Duncan darren-at-darrenduncan.net |Perl 6| wrote: >>>> So, how does one get an object to pretend to be a value type for >>>> purposes of assignment? >>> >>> I have been under the impression that value types are supposed to >>> define immutable objects, or at least objects that pretend to be >>> immutable; any operators on them would produce new objects rather than >>> mutating existing ones. >>> [...] >> >> I agree. A "value type" is "immutable", where the identity is keyed to >> the value. Making a "value type" that can mutate can cause confusion. >> >> I'm now thinking that the normal = you write should always give >> reference assignment semantics. In the case of "value types", assuming >> they are indeed immutable, it does not matter whether they have value or >> reference assignment semantics, since the same value will give the same >> identity, regardless of memory (or in-register) representation. >> [...] > > I think I can accept this reasoning for now, although it has some > strong implications for managing array elements and binding operations > (especially given Parrot's model of them). But we'll come up with > something, and thanks. > > Pm >
I don't understand how = differs with that semantic from := I would expect that = would make a copy (clone?) of the object. For a mutable object, I don't know if that copy should be immediate or deffered by a mechanism of copy on write. Probably that behavior could depend on a trait of the class that implements to be copied object. -- cognominal stef
