Re: equal tag method [was Re: unicode and locale again]

[RLake@...]

If I have to use rawequals() instead of ==, then there is a function call.
So the situation is that if I want object equality then I'm guaranteed the
overhead of a function call; otherwise, I have the possibility of a
function call.

What I object to is that object equality is (I assume) still the criterion
for table key comparison, but it is no longer the definition of ==.

Would it really be too difficult to add === ? Or something similar?

By the way, if you want to be complete in front of partial ordering, you
end up with at least 14 comparison operators, not counting object equality
and object inequality.

Alternative suggestion: conflate "nil" and "NaN". Then define the
relational operators (other than == and ~=) to short-circuitedly return
"nil" if that is the first argument. Add the function isnil() instead of
the function rawequals(). (Alternatively, replace nil with false throughout
the previous suggestion.) That can at least be made meaningful on
non-floating-point (or non-IEEE-754) platforms.

Rici



                                                                                                                          
                    Roberto                                                                                               
                    Ierusalimschy               To:     Multiple recipients of list <lua-l@tecgraf.puc-rio.br>            
                    <roberto@inf.puc-rio        cc:                                                                       
                    .br>                        Subject:     Re: equal tag method [was Re: unicode and locale again]      
                    Sent by:                                                                                              
                    owner-lua-l@tecgraf.                                                                                  
                    puc-rio.br                                                                                            
                                                                                                                          
                                                                                                                          
                    27/06/02 08.07                                                                                        
                    Please respond to                                                                                     
                    lua-l                                                                                                 
                                                                                                                          
                                                                                                                          




> However, there was (I thought) general agreement that we could compromise
> on partial ordering with the <, <=, =>, and > operators, leaving == and
> it's converse (which I cannot easily type on a Windows Spanish keyboard)
to
> mean object identity.

The equal tag method is not for partial order. We implemented partial order
along the line pointed out by Reuben Tomas (an optional __le method).

The equal tag method is for completeness. It is strange that you can
define <, >, <=, and >=, but not == .


> Changing object identity to a function call would add far far too much
> overhead to what should be a basic operator.

There is a function call only when there is a tag method; they are only
checked when comparing tables or userdata. So the overhead is minimal,
with no overhead at all when comparing primitive types.

-- Roberto