Ter, 2008-04-29 às 14:21 +0200, TSa escreveu:
> Daniel Ruoso wrote:
> > Not really... 'does' is a composition operation, 'realises' would be
> > just a type annotation that doesn't change the actual composition.
> OK, but that is not in the spec yet. To me that is like the
> proposed 'like' operator but with the programmer taking full
> responsibility. Like reinterpret_cast in C++.

It doesn't need to be. New traits can be implemented later.

> First of all assignment has copy semantics. That is after $y = $fp,
> $y =:= $fp is false. I agree that

It will copy the scalar, which means that later change in the value cell
won't propagate to the other variable. But both cells point to the same
value.

     $a = $b;
     $a === $b; # TRUE
     $a =:= $b; # FALSE
     $b = $c;
     $a === $b; # FALSE

As opposed to

     $a := $b;
     $a === $b; # TRUE
     $a =:= $b; # TRUE
     $b = $c;
     $a === $b; # TRUE

In the later, the scalar itself is copied, which means that both
variables *are* the same scalar, and changing the cell value in one is
the same as changing the cell value in the other.

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.

> But either the HOW, the WHAT or both of $fp have to change

That is true

> which implies that $y === $fp can't remain true after
> $fp does Point

Not really... see below...

> 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.

> > It doesn't. By definition. === only checks WHICH.
> Then we must read different versions of S03. Mine has the
> sentence "Two values are never equivalent unless they are
> of exactly the same type."

*Value types*!!! Which is not the case here, we are talking about
*Object types*, also in S03:

   for two mutable types (object types), checks whether they have the
   same identity value. (For most such types the identity is simply the
   reference itself.)

Which means that (continuing the code starting with "class A")...

   $a = A.new(a => 0);
   $b = $a;
   $a === $b; # TRUE
   $b.inc;
   $a === $b; # TRUE

daniel

Reply via email to