Re: FFI enums are now always boxed
- From: Francesco Abbate <francesco.bbt@xxxxxxxxx>
- To: luajit@xxxxxxxxxxxxx
- Date: Thu, 19 Jul 2012 11:25:12 +0200
2012/7/17 Mike Pall <mike-1207@xxxxxxxxxx>:
> This change may break compatibility with existing programs using
> the FFI, if you pass an enum to a non-FFI function. Hopefully this
> is not very common. You may need to explicitly convert the enum to
> a plain Lua number with tonumber(). Or better declare the field or
> return value as an integer, if it's usually treated like a number.
>
> A new feature is that comparisons and arithmetic operations
> automatically convert a string operand that matches an enum
> constant to its value, provided the other operand is an enum. This
> is the same implicit conversion that's used for storing to enum
> fields/elements or passing enum arguments (already worked before):
Hi all,
I'm a little bit perplexed about how the overload of equality
relational operators works with strings. I understand the logic and
the usefulness of having enum that knows about theirs literal values.
I've got myself a few situations with the GSL library where this
feature could be handy but there are some issues with string
comparison. I think that make the equality operator return true on
string comparison does violate some very basic rules about the
equality operator.
For example, look at this weird behavior from your snippet example:
bar.e == "AAA" '-- this is true
tonumber(bar.e) == tonumber("AAA") -- this is false
foo(bar.e) == for("AAA") -- can raise an error if foo is a function
that take an integer
This may seems unimportant but it does really undermine the underlying
logic of the equality operator.
But there is also a more important problem:
n = 1
n == bar.e -- true
bar.e == "AAA" -- true
n == "AAA" -- false
so the transitivity of equality comparison is violated (aaargh this
looks like javascript :-) ). I believe this alone should be enough to
roll back this feature about equality with strings. Of course, for the
other side, equality with numbers is just fine.
May be you can introduce instead something like:
bar.e == ffi.enum"AAA"
where ffi.enum does the required lookup but if I understood correctly
this is expensive to implement.
An alternative could be also:
ffi.enum(bar.e) == "AAA"
where ffi.enum takes the enum cdata and return its literal string
representation ?
These are just some quite straightforward suggestions but I strongly
advice to remove the string equality feature of enumerations.
Francesco
Other related posts:
