[ I'm using this message to reply, because I didn't receive your
reply... I'm taking it from the list history... There really seems to be
something wrong with this list... ]

´╗┐TSa wrote:
> BTW, is WHICH globally unique? Or is that also an
> implementation detail?

This is not specced apparently to leave room for decision in the
implementation. But there's an important question to be answered before

what is the type returned by WHICH?

I haven't implemented that in SMOP yet (because I have the constant
identifiers that allow me to make simple pointer comparison), but I
think in the low-level it will end-up being something like a native
binary blob.

Which means that every non-native type will, in the end, have to be
reduced to native types in the WHICH call to provide a proper value for

TSa wrote:
> 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

But it's important to keep in mind that eqv behaviour might also be
overriden by the object, that might give a canonical representation that
matches the other object.

An implementation of the 'realises' trait could make its canonical
representation unchanged.

As I said earlier, 'does' is an composition operator, it will change the
class composition, therefore making it a different object.

On the other hand, a 'realises' trait could change the object in order
that it would still match with both 'eqv' and '===', while still '~~' to
an additional type.

This would be done simply by creating an anonymous class that isa the
original class while overriding .^does, WHICH and eqv to shadow to the
original class, and then re-blessing the object to this anonymous class.

TSa wrote:
> 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

It doesn't need to be part of the spec, it's a simple module that
traverses .^methods to check if $a implements all methods described by
$b. You might want to implement it already in other to "reserve" the
name ;).


Reply via email to