Front page | perl.perl6.language |
Postings from April 2008
HaloO,
Daniel Ruoso wrote:
> So...
>
> class A { has $.a; method inc { $.a++ } };
> $a = A.new( a => 0);
> $b = $a;
> $b.inc();
> $a.inc();
> say $a.a; # 2
> say $b.a; # 2
>
> Will work as expected.
Depends a bit on one's expectations :)
So infix:<=> has shallow copy semantics. IIRC, there was once
an 'is deep' trait. Otherwise one has to implement
multi infix:<=> (Any $lhs, A $rhs)
{
$lhs.STORE($rhs.clone); # or .cow if that's not automatic
}
>> But either the HOW, the WHAT or both of $fp have to change
>
> That is true
So, even though the WHICH stays the eqv check has to change:
$a = A.new( a => 0); # your class A
$b = A.new( a => 0);
$a === $b; # False, but
$a eqv $b; # True because of snapshot semantic
$b does Point;
$a eqv $b; # False because HOW or WHAT is different
BTW, is WHICH globally unique? Or is that also an
implementation detail?
The snapshot check is of course type aware:
class B { has $.a; method inc { $.a++ } };
$a = A.new( a => 0); # your class A
$b = B.new( a => 0); # same structural type
$a eqv $b; # False because of type mismatch
Funnily this implies we also need a version of eqv
that uses like or duck semantics. But this seems to
be foreseen. Could someone post the signature to use
for eqv() to make $a and $b to compare equal structurally
here? Is it eqv($a, $b, :(like A, like A))? Perhaps
that can be abbreviated to eqv($a, $b, :like)? Or even
infix:<like> with the rational that this always is a
test not a modifying call like infix:<does>. But I would
like to reserve infix:<like> for a type check without
subsequent canonical value comparison. That is continuing
from above
$b.inc;
$a like $b; # still true even though $a.a != $b.a
Or the structural type test is similar to .does
$a .like: $b;
>> BTW, an interesting question is if a typed
>> binding could become invalid:
>> subset AntiPoint of Any where {not .^does(Point)}
>> my AntiPoint $ap := $fp; # fine for now
>> $fp does Point; # now $ap is bound to a Point which
>> # violates the AntiPoint constraint
>
> This is a composition error that generates an exception. It even
> provides enough information for a compile-time error.
Where is it raised? In the '$fp does Point;' statement with
the error "can't compose role Point because of AntiPoint binding
to $ap"? How would that change if the line read
my AntiPoint $ap = $fp; # or with real assignment
# after the declaration
Would it say "can't compose role Point because of AntiPoint
reference in $ap"? How far does that reach? I mean does the
meta object system know about the constraints of all bindings
and stored references to an object?
Regards, TSa.
--
"The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
Thread Previous
|
Thread Next