Patrick R. Michaud wrote:
In [1], Larry writes:

[...] we left = in the language
to provide (to the extent possible) the same semantics that it
does in Perl 5.  And when it comes to non-value types, there really
are still references, even if we try not to talk about them much.
So I think assignment is basically about copying around identities,
where value types treat identity differently than object types (or
at least, objects types that aren't pretending to be value types).

So, how does one get an object to pretend to be a value type for
purposes of assignment?
Currently if I do the following

    class Dog { ... }
    my $a =;
    my $b = $a;

then $a and $b both refer to the same Dog object.  How would I
define Dog such that it acts like a value type -- i.e., so that
$b would be a copy of $a and future changes to the object in $a don't affect $b.

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. Therefore assignment can actually work the same way for all types, whether value types or not, by making the LHS container just hold an additional reference to what the RHS container holds. Since the value types are effectively immutable, there is no harm to them not being copied by default, and in fact this would be a feature, making it simpler to avoid unnecessary work.

If you are wanting to actually mutate a Dog in a user-visible way rather than deriving another Dog, then I don't think that calling Dog a value type is appropriate.

-- Darren Duncan

Reply via email to