lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index] 

Rici Lake wrote:


...
Just to harp on another issue, I was very proud when I overrode all the arithmetic opcodes to be able to handly my "primitive objects". My system has objects, for instance SFFloat, which are wrappers around primitives (float in this case). If I have: 

    local a = SFFloat(1)

I really want to go:

    local b = a + 5
So I overrode __add and simply converted the object to a primitive, did the add and returned the result.
I can't help thinking that it would be easier to convert the SFFloats to numbers when you introduce them into the Lua environment, and back to SFFloats when you export them. Again, this could easilly be done with getter/setter methods.
The whole point of having objects represent primitives is because they have extra functionality, like firing events which can be routed to properties of other objects. So Lua really needs to know about their object-ness. And the whole point of making this author-friendly is to avoid getter and setter methods. 




 Cool! Well, when I overrode __lt so I could do this:

    if a < 5 then ...
it didn't work because the logic around __lt requires that both sides of the operator are the same type!
Actually, it only requires them to have the same metamethod. In Lua 5.1, primitive types have metatables, so you could define the __lt metamethod for Lua numbers to be the same metamethod as your Numeric types. This wouldn't slow down Lua's actual numeric comparisons since the Number metatable isn't consulted. Having said that, I haven't checked the code to see whether that will work -- it may be that Lua still insists that comparable objects have the same Lua type -- but the patch would be a lot cleaner.
Right, I have thought that the new primitive metatables might help me. But I have not fiddled with them yet. 


...
It would be nice if there were __toboolean and __tonumber metamethods, just like there is __tostring.
This wouldn't really work in the case of __tonumber; you would have to restrict it to the tonumber() explicit coercion. 

Suppose you had   a + b

where a and b are objects. Does this mean

  meta(a):__tonumber(a) + meta(b):__tonumber(b)

or

  meta(a):__add(b)

(Consider the case of a Complex object type to put that into perspective.)
Couldn't you have a rule that first tried the first way and if that did not work (because there is not __tonumber metamethod for that object, for instance) you would try __add? I agree that __add is needed for things like complex numbers. I don't happen to have that issue, though. 


...
Anyway, that didn't happen and I'm not really disappointed. (I'd still be happy to go back to only 'nil' testing false, though.) One of the things I really like about Lua is that 0 and "0" and {} are all true. (Particularly "0".) If you mean something different you should say it.
I was pissed off at first that 0 tested true in Lua. I've never seen another mainstream language that does this. But I am not too mad about it. I have no problem forcing my authors to do: 

    if a == 0 then ...
I have had to resort to a valueOf() method on these objects. So you have to go: 

    if c:valueOf() then ...

not bad, but not very friendly to the authors either!
Friendly to the authors would be not trying to wrap true and false as pseudo-objects, or using the 5.1 metatables to do so. Failing that, I'd go for: 

    if c == SFTrue then ...

or

    if c ~= SFFalse then

or even

    if Boolean(c) then
But for all intents and purposes an SFBoolean object IS a boolean primitive. The extra features that SFBoolean provides has nothing to do with its data type, only with how it can interact with other properties in the system. What I really want is for Lua not to judge me for how I want to coerce the object system :-)
in preference to c:valueOf(), which doesn't give me much of a hint what it's supposed to do.
This brings up what seems to be a dirty word here and many other language oriented places, Javascript. I say that because I see people all over the place mention the "top languages" as Python, C++, Java, event Self (which I have taken to be a codeword for Javascript). I'm not sure why that it. Is it because Javascript has been erroneously associated with Java by its poor naming, or is it because people don't like to type ECMAScript, or is it because it has to much of the cachet of that other persona non grata language, Basic? It's almost like saying Voldemort in the Harry Potter books! But it is one of the most popular languages in existance, given the millions of web pages it appears on.
Anyway, many of these concepts come from The-Language-That-Must-Not-Be-Named.
In particular, valueOf() returns a string, number or boolean primitive if the object is naturally of that type. Otherwise it returns the object that was passed. It is used to solve this exact problem. It is hardly ever used in Javascript because it does all these transformations implicitly.
Anyway, my goal is to get as many Javascript features into the Lua-based Object Model as possible. I am even considering writing a Javascript-to-Lua translator so my authors can use that syntax. That will solve the "Lua is just too oddball" complaint I am getting. This solution may not provide as rich a solution as Lua is capable of. But native Lua will still be there when needed so nothing will be lost! 

--
chris marrin              ,""$, "As a general rule,don't solve puzzles
chris@marrin.com        b`    $  that open portals to Hell" ,,.
        ,.`           ,b`    ,`                            , 1$'
     ,|`             mP    ,`                              :$$'     ,mm
   ,b"              b"   ,`            ,mm      m$$    ,m         ,`P$$
  m$`             ,b`  .` ,mm        ,'|$P   ,|"1$`  ,b$P       ,`  :$1
 b$`             ,$: :,`` |$$      ,`   $$` ,|` ,$$,,`"$$     .`    :$|
b$|            _m$`,:`    :$1   ,`     ,$Pm|`    `    :$$,..;"'     |$:
P$b,      _;b$$b$1"       |$$ ,`      ,$$"             ``'          $$
 ```"```'"    `"`         `""`        ""`                          ,P`