lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

Hi Jose :-)

Sorry for so late to reply your letter. For overload, maybe we can make some simple simulation.

Class< Foo >(“Foo")
    .construtorOverloaded<int, int>()
    .setOverloaded<>("func", &Foo::func) 
    .setOverloaded<int, int>("func", &Foo::func) 

For *Overloaded method of Class, just add functions into a list. When call function, e.g. constructor or func, we can just compare the argument's types to decide which function to call. the compare is in order, i.e. if you register two function that matches the the same signature, then the first will called. 

2010/12/27 Jose Luis 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

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

methods registered:

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(unsigned int)
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.


On Sun, Dec 26, 2010 at 8:18 PM, starwing <> wrote:
> Hi Jose,
> thank you to reply :-)
> 2010/12/27 Jose Luis Hidalgo <>:
>> Hi starwing,
>> On Sun, Dec 26, 2010 at 7:23 PM, starwing <> 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)
>>   ---- ----

  Jose L. Hidalgo Valiño (PpluX)
  ---- ----