Daniel Ruoso wrote:

     class A { has $.a; method inc { $.a++ } };
     $a = A.new( a => 0);
     $b = $a;
     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


   $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

Reply via email to