[boost] Re: Interest in luabind

From: David Abrahams (dave_at_[hidden])
Date: 2003-06-18 08:40:20

Moving this to the C++-sig as it's a more appropriate forum...

"dalwan01" <dalwan01_at_[hidden]> writes:

>> Daniel Wallin <dalwan01_at_[hidden]> writes:
>>
>> > At 18:03 2003-06-17, you wrote:
>> >>http://aspn.activestate.com/ASPN/Mail/Message/c++-sig/1673338 is
>> >>more recent and also relevant to your question.
>> >>
>> >>In short, I'd love to see luabind in Boost, and I'd hate to see
>> >>it happen without substantial code sharing with Boost.Python.
>> >
>> > I agree. It seems like a lot of code could be shared.  For
>> > instance, the conversion system between base<->derived should
>> > work exactly the same and we could probably plug in BPL's system
>> > for this without much trouble.
>> >
>> > It would also be really nice if we could share most of the
>> > front-end code (declaration of scopes, classes and functions).
>> >
>> > Note however that there are quite a few differences in design,
>> > for instance for our scope's we have been experimenting with
>> > expressions ala phoenix:
>> >
>> > namespace_("foo")
>> > [
>> >    def(..),
>> >    def(..)
>> > ];
>>
>> I considered this syntax but I am not convinced it is an advantage.
>> It seems to have quite a few downsides and no upsides.  Am I
>> missing something?
>
> For us it has several upsides:
>
>   * We can easily nest namespaces

IMO, it optimizes for the wrong case, since namespaces are typically flat
rather than deeply nested (see the Zen of Python), nor are they
represented explicitly in Python code, but inferred from file
boundaries.

>   * We like the syntax :)

It is nice for C++ programmers, but Python programmers at least are
very much more comfortable without the brackets.

>   * We can remove the lua_State* parameter from
>     all calls to def()/class_()

I'm not sure what that is.  We handle global state in Boost.Python by
simply keeping track of the current module ("state") in a global
variable.  Works a treat.

> What do you consider the downsides to be?

In addition to what I cited above, 

a. since methods and module-scope functions need to be wrapped
   differently, you need to build up a data structure which stores the
   arguments to def(...) out of the comma-separated items with a
   complex expression-template type and then interpret that type using
   a metaprogram when the operator[]s are applied.  This can only
   increase compile times, which is already a problem.

b. You don't get any order-of-evaluation guarantees.  Things like
   staticmethod() need to operate on an existing function object in the
   class' dictionary
   [http://www.boost.org/libs/python/doc/v2/class.html#class_-spec-modifiers]
   and if you can't guarantee that it gets executed after a def()
   call you need to further complicate your expression template to
   delay evaluation of staticmethod()

I guess these two are essentially the same issue.

>> > Also, we don't have a type-converter registry; we make all
>> > choices on what converter to use at compile time.
>>
>> I used to do that, but it doesn't support
>> component-based-development has other serious problems.  Are you
>> sure your code is actually conformant?  When converters are
>> determined at compile-time, the only viable and conformant way
>> AFAICT is with template specializations, and that means clients
>> have to be highly conscious of ordering issues.
>
> I think it's conformant, but I wouldn't swear on it.
> We strip all qualifiers from the types and specialize on
>
>   by_cref<..>
>   by_ref<..>
>   by_ptr<..>
>   by_value<..>
>
> types. 

How do people define specialized converters for particular types?

> It works on all compilers we have tried it on (vc 6-7.1,
> codewarrior, gcc2.95.3+, intel).

Codewarrior Pro8.x, explicitly using the '-iso-templates on' option?
All the others support several common nonconformance bugs, many of
which I was exploiting in Boost.Python v1.

> For us it doesn't seem like an option to dispatch the converters at
> runtime, since performance is a really high priority for our users.

What we're doing in Boost.Python turns out to be very efficient, well
below the threshold that anyone would notice IIUC.  Eric Jones did a
test comparing its speed to SWIG and to my great surprise,
Boost.Python won.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com