Front page | perl.perl6.language |
Postings from September 2008
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 = Dog.new;
> 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
Thread Previous
|
Thread Next