Re: More on environments and objects

[Chris Marrin <chris@...>]

Rici Lake wrote:
> On 27-Aug-05, at 10:44 PM, Chris Marrin wrote:
>
> > If I found this acceptable:
> >
> >     local a = SFBoolean(true)
> >     if a == SFTrue then...
> >
> > then all would be well. But I don't. Even these two:
> >
> >     if a == true then...
> >     if a:valueOf() then...
> >
> > which both work after I made my "fix" to __eq, is not acceptable to 
> > me. It has to be:
> >
> >     if a then...
> >
> > so I will have to make the change to the VM.
>
>
> Now you're just being stubborn :)

:-)

> ...
> By the way, I checked the 5.1work6 code. It still insists that objects 
> have the same (lua) type in order to be compared, so it won't do what 
> you want. It would be easy-ish to change the check to "same metamethod" 
> with a little jiggling.
> ...

Yes, this is essentially what I have done to __eq, __lt and __le.

> I haven't tried any of that, and I'm don't think I like it. I would 
> certainly want to have an non-overridable object equality primitive in 
> the language ('is' '===' or however you spell it).

Agreed. But for the rarity of its use. I would not consider it critical 
that it were a language primitive. I would find something like:

    if a.isSameObjectAs(b) then...

to be perfectly acceptable. Many of these "simplicity" requirements 
don't come from my twisted brain, but from those of my collegues who are 
heavy non-programmer advocates. For them, there are really two classes 
of authors. Those who really need to be able to write obvious scripts 
without giving much thought to the underlying mechanisms. To them, 
SFBoolean is a boolean primitive so there is absolutely no reason you 
shouldn't be able to test it in an if statement. Then there is the class 
of authors who need to squeeze more out of the language. These folks are 
the ones to create new classes for the other authors to use. So they can 
dig in and understand more so they can, for instance, figure out the 
difference between testing to see if the values of two objects are the 
same and testing to see if the objects are the same. We have the "keep 
simple things simple, and make complicated things possible" philosophy.

--
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`