HaloO, 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 that... 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
