Will operator '==' support fulluserdata and number or nil or false

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Will operator '==' support fulluserdata and number or nil or false

奥斯陆君王
I think the following two statement should be equal
1.    v>= 1 and v <= 1
2.    v== 1
Howerver, they may produce two different result for a userdata or a
table that override the metamethod correctly(ignore the bad cases).
Provide a way to let them result both true?
For compatiblity, other than allow it for __eq metamethod, a better
way will be add a new metamethod entry like __peq (equal to primitive
type).

I got the idea when I found out there is no way to make
ffi.new('int',1)==1 for standard lua. I think you may advise me to add
a method like ffi.equals or patch the vm by myself(patch every
version? a diff file?).  All of them are possible ways. But if lua
does support it, it will be less time-consuming to port luajit codes
to lua since luajit seems dying.

Reply | Threaded
Open this post in threaded view
|

Re: Will operator '==' support fulluserdata and number or nil or false

Dirk Laurie-2
Op So. 24 Feb. 2019 om 10:49 het 奥斯陆君王 <[hidden email]> geskryf:
>
> I think the following two statement should be equal
> 1.    v>= 1 and v <= 1
> 2.    v== 1

I disagree. It is a fundamental principle of Lua that values of
different types are not equal.

But let's read a little further.

> Howerver, they may produce two different result for a userdata or a
> table that override the metamethod correctly(ignore the bad cases).
> Provide a way to let them result both true?
> For compatiblity, other than allow it for __eq metamethod, a better
> way will be add a new metamethod entry like __peq (equal to primitive
> type).
>
> I got the idea when I found out there is no way to make
> ffi.new('int',1)==1 for standard lua. I think you may advise me to add
> a method like ffi.equals or patch the vm by myself(patch every
> version? a diff file?).

I do advise you to add a method, not an equals method, but a cast
method, so that v:cast(1) returns
a value of the same type (and subtype, if applicable) as v, and then
you can cleanly test for v==v:cast(1).
If you are a keystroke saver, make cast your __call metamethod, and
test for v==v(1).

> All of them are possible ways. But if lua
> does support it, it will be less time-consuming to port luajit codes
> to lua since luajit seems dying.

Stagnating, maybe. Not dying. The source code is still being included
in its entirety in numerous active projects.

Reply | Threaded
Open this post in threaded view
|

Re: Will operator '==' support fulluserdata and number or nil or false

奥斯陆君王
In reply to this post by 奥斯陆君王
I just want to compare a number and a fulluserdata, and I know it's
important to ensure value of different type not equal. But only
compare number and fulluserdata won't affect anything. Secondly, tt
doesn't break any rule in current __eq metamethod, because a new
metamethod will be used. Thirdly, It doesn't affect performance,
because only number type will be affected and fastmt will make sure
only one table search will be performed if the userdata doesn't define
such a metamethod. Fourth, fasttm tag still 3 bit unused. Fifth, If
you want to make sure the value is number, a type check will be faster
and safer than an equal call. If comparsion for string and number is
ok, why can't it be extended.

Reply | Threaded
Open this post in threaded view
|

Re: Will operator '==' support fulluserdata and number or nil or false

Dirk Laurie-2
Op So. 24 Feb. 2019 om 14:50 het 奥斯陆君王 <[hidden email]> geskryf:

>
> I just want to compare a number and a fulluserdata, and I know it's
> important to ensure value of different type not equal. But only
> compare number and fulluserdata won't affect anything. Secondly, tt
> doesn't break any rule in current __eq metamethod, because a new
> metamethod will be used. Thirdly, It doesn't affect performance,
> because only number type will be affected and fastmt will make sure
> only one table search will be performed if the userdata doesn't define
> such a metamethod. Fourth, fasttm tag still 3 bit unused. Fifth, If
> you want to make sure the value is number, a type check will be faster
> and safer than an equal call. If comparsion for string and number is
> ok, why can't it be extended.

Comparison for string and number is not ok.

> 1<"1"
stdin:1: attempt to compare number with string
stack traceback:
    stdin:1: in main chunk
    [C]: in ?