HaloO,
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++.
This way, the dispatching mechanism is still the same (and still typed),
but the object now also answers true to .^does(Point).
But note that
FoxPoint $fp = ...;
$y = $fp;
$y === $fp; # obviously true
$fp does Point;
$y === $fp; # false because of different HOW?
Wrong. $fp is still the same object and $y would also answer true
to .^does(Point). it's an in-place change, not a copy. you would need to
do
$y = $fp.clone();
First of all assignment has copy semantics. That is after $y = $fp,
$y =:= $fp is false. I agree that
$before := $fp;
$fp does Point;
$fp =:= $before; # maintain referential identity
But either the HOW, the WHAT or both of $fp have to change
which implies that $y === $fp can't remain true after
$fp does Point. 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
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."
Regards, TSa.
--
"The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
