Re: Implicit casting issues when binding to C++
- From: Michal Kottman <k0mpjut0r@xxxxxxxxx>
- To: luajit@xxxxxxxxxxxxx
- Date: Sat, 7 Jul 2012 21:58:59 +0200
On 7 July 2012 20:44, Coda Highland <chighland@xxxxxxxxx> wrote:
>> That, again, to me seems incredibly unworkable. Implicit casts are a
>> conventience in C, in a scripting language you'd definitely not expect a
>> user to have to think about them. The end result would be that, to be on the
>> safe side, you'd do proper casting everywhere and the type conversion has
>> become obsolete because of it's own limitation. So the mere fact that it
>> exists makes it a hazard to its own existence?
>
> The main time to disagree is when those implicit casts represent
> objects that SHOULDN'T be mapped in Lua: The script user shouldn't be
> expected to deal with QString at all, but should be allowed to pass
> Lua strings at all appropriate times.
We had issues with implicit conversions in lqt. At first, Lua strings
were mapped directly to QString. You tend to use QString a lot, mainly
when constructing the GUI using Lua code. The mapping meant that you
could write QPushButton.new("Button label") and it worked.
However, QString has several useful methods, which were lost in the
conversion (you dealt only with Lua strings, which were mapped to
QStrings in lqt). So a decision was made to map Lua string to
QByteArray instead (which was really a better idea, since QByteArray
represents a sequence of bytes of a certain length, which is exactly
what Lua string is). However, this decision meant that you had to type
the QString constructor everywhere (which as I said is a lot, when
implementing the GUI yourself). I used this shortcut, but it was not
nice:
function Q(s) return QString.fromUtf8(s) end
btn = QPushButton.new(Q"Push button label")
Finally, I implemented implicit casting for constructors respecting
the C++ semantics (at least as I understood it :). This means now you
can write your code as before (QPushButton.new("Label") ) but still be
able to use QString and its methods, since it is not mapped to Lua
string.
TL;DR implicit casting is useful, in my case when constructing the GUI
in Lua code and dealing with string conversions. How this could be
implemented with the FFI is questionable (a "__construct" metamethod
maybe? therefore only types created using ffi.metatype would be
"slowed down" by the conversions...)
Other related posts:
