Daniel Ruoso wrote:
[ 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... ]

I see all your messages arrive twice.

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?

Isn't that up to the implementation as well? E.g. on a 32bit platform
use an unsigned 32bit integer. The only things that should not happen
is that you let it leak onto the value level or that WHICHes of
differently typed objects are compared.

With leaking to the value level I mean allowing $x.WHICH == 42 even
if it is known that WHICH is implemented with a number.

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.

Ups, no object can override eqv or any other binary method. These
live outside of HOW space. You can insert your dispatch targets
but that's about it.

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.

I don't understand your motivation, but I think it is the obsession with
object identity. You say that the object changes class, i.e. its HOW or
WHAT changes while perhaps keeping its WHICH. But eqv, === and ~~ are
defined outside of the class or object system. There is an inheritance
order on HOW space and a subtyping order on WHAT space. Class based
dispatch goes along the former, type based dispatch along the latter.
The object that changes class should not be eqv or === to itself before
the transition or nominal typing becomes absurd.

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