Re: SLB vs LuaBind

[Jose Luis Hidalgo <joseluis.hidalgo@...>]

Hi starwing,

   I'm sorry but I've been strugling with this for a long time, and
the last thing I want is to have a non deterministic solution. For
example:

Class A;
Class B : public A; //< inherits from A

methods registered:

foo(A*)
foo(B*)
foo(A*, B*)
foo(B*, A*)

now in lua:

a = A();
b = B();

foo(b)     (1)
foo(a,b)  (2)
foo(b,a)  (3)

(1) --> it makes perfectly sense to call both foo(B*) or foo(A*), it
makes a bit more sense to call foo(B*) though, but that now implies
you have to score the functions somehow, if it fails with foo(B*) then
call foo(A*), what happens if instead of a simple relationship we have
multiple inheritance? it's even worse.

(2) & (3) -> again here we have to score to see which functions fits
better the arguments, and if the user wants the
non-best-fit-but-still-valid call we have to add a new way to call the
other function.

Other problem is that in SLB when you receive a A* instance from a
function in C, it determines if the object is indeed an object from A*
or from B*, and if it is from B* it will in fact use the deepest and
more richer class for that object (B*), so it will have all the
methods from A* and B*. That means that we can't use casting as in C
to determine which function to call, this is good though, because lua
is a very powerful dynamic language and SLB mimics that from C++ which
is not.

And then we have the basic lua types against C++ types, you said we
can define a table, but still we will have problems:

foo(double)
foo(float)
foo(int)
foo(unsigned int)
foo(long)
foo(unsigned long)

now from lua...

foo(5) --> which is valid right now for any of the above...

So the simplest, more elegant solution, right now, is not supporting
overloading, I'd rather a quick, stable, and deterministic wrapper,
that lots of rules, that will at the end fail somewhere. If you have a
solution for all the cases, I'm open to any kind of suggestion.


Regards,
   JL.




On Sun, Dec 26, 2010 at 8:18 PM, starwing <weasley.wx@gmail.com> wrote:
> Hi Jose,
>
> thank you to reply :-)
>
> 2010/12/27 Jose Luis Hidalgo <joseluis.hidalgo@gmail.com>:
>> Hi starwing,
>>
>> On Sun, Dec 26, 2010 at 7:23 PM, starwing <weasley.wx@gmail.com> wrote:
>>> Does SLB support function overload? it's a useful feature.
>>>
>>
>> Mmm... sorry, but no. The problem is lua type marshaling with C++
>> types, there are many ways a type can be "converted" from lua to a C++
>> function/method signature. Overloading could be possible for different
>> number of arguments, though, but no for different signatures with the
>> same number of arguments, and I didn't want to support partial
>> overloading.
>
> Maybe we can make a typemap table to handle the type conversion
> between lua and C++.
>
>
>>
>> BTW, the search for the proper method to call will add a significant
>> overhead, SLB is meant to be as faster as possible, near to a
>> hand-coded wrapper. What I usually do with overloading is register
>> each function with a different name in lua, which is not as handy as
>> overload support, but it works.
>>
>
> No, It will every fast, In a typical implement, we can store C
> functions into a hash table, the key is the type-signature. so to find
> the right function, we just lookup a hash table, and the global
> variable lookup in Lua is just lookup a hash table. so it can not slow
> than reference a global variable in Lua.
>
> and, If we want, just use a different function in SLB to register
> overloaded function, most function needn't lookup hash table, but if
> we need, we can use it. is it better than no overload support?
>
>
>> Cheers,
>>   JL.
>>
>> PS: I'm working on registering accessors to instances' attributes,
>> but, I'm not sure about how use it from lua properly, do you have any
>> insights?
>>
>> --
>>   Jose L. Hidalgo Valiño (PpluX)
>>   ---- http://www.pplux.com ----
>>
>>
>
>



-- 
  Jose L. Hidalgo Valiño (PpluX)
  ---- http://www.pplux.com ----