Re: comparison operators for user defined types?

[Mike Pall <mikelu-0507@...>]

Hi,

Chris Marrin wrote:
> But this does not work for __lt. If you look at luaV_lessthan() you can 
> see that it is because both operands must be of the same type and have 
> the same metamethod. It seems like the same logic could be used (call 
> either metamethod, preferring the one for the left operand). Is there a 
> reason it was done this way? I looked at both 5.02 and work6 and they 
> were both the same.

Lua uses the 'pure' definition for object comparison: there is no
ordering relationship between objects of different types. This is
in line with the Lua definition of object equality as object identity.
So from a language design standpoint this is very consistent.

Because when you allow SFFloat(5.2) < 4.7, then you really should make
SFFloat(5.2) == 5.2 return a true result, too (difficult, but doable
with automatic type coercion). But then you better ensure that
table[SFFloat(5.2)] does the same as table[5.2]. This is where you get
into real trouble (we had a similar discussion a few weeks ago).

Umm, and automatic type coercion is troublesome, anyway -- have
a look at the implementation of some languages that do this.
I personally dislike the implicit string/number coercions in Lua,
too (but I guess this is a convenience vs. purity issue).

[And I have to add, that for my next bigger project (to be released
 soon) the 'pure' language definition of Lua makes things an order
 of magnitude easier.]

So to summarize: the standard Lua operators won't help you here.
Either use only canonical types or define your own operators,
e.g. lt(SFFloat(5.2), 4.7). You loose the infix syntax, but
you'll get used to it.


[BTW: quality(your.signature) < quality(your.postings)
 It's hard to justify responding to someone with a skr1pt k1dd13 sig.]

Bye,
     Mike