Re: What does metamethod equality mean? (long) (Was: Re: Need for help)

["Peter Hill" <corwin@...>]

RLake:
> I am neutral on the issue of "type" equality checking for __lt but adamant
> for __eq: I do not want objects floating around which can defeat __eq and
> I think that calling raweq is ugly.

> As I have said before, if __eq is generalised enough to allow an object to
> hijack it, it should have its own operator and == should go back to being
> strict object identity (whatever that might mean in the context of the
> above discussion on closure equality.) Object identity and object
> "equality" are two different things, and recognising that is important.
>
> In the end, almost all languages end up with two different "==" operators.
> (Scheme ended up, bizarrely, with three.) It is, unfortunately,
> complicated for both programmers and non-programmers, but I don't think
> that avoiding the issue makes it any simpler. I accept that a polymorphic
> == is easier for most people to get their heads around and that object
> identity is a "more advanced" concept; but "raweq(a,b)" just doesn't do it
> for me. I like "is" as in:
>
> if a is nil then ...

It is an interesting question as to how often, in current code, people rely
on '==' meaning "identical references". It certainly seems to me that the
"==" symbol should be granted to the most common usage.

> (And on a theoretical level, I think that the operator used for table key
> comparison should be a language primitive.)
> I think that captures the idea of what object identity means.

Which makes me wonder... if table key comparison was extended to include an
"eq" metamethod would there be any remaining need for a "reference
equivalence" test? It is not that unreasonable that two "__eq" values might
key the same for a table...

*cheers*
Peter Hill.

Ki: Contractors... high-paid leeches stealing our work.
Fooker: If you think of them as disposable employees, you'll feel much
better...