|
Boost : |
From: David Abrahams (dave_at_[hidden])
Date: 2003-06-17 19:29:15
Daniel Wallin <dalwan01_at_[hidden]> writes:
> At 18:03 2003-06-17, you wrote:
>>Daniel Wallin <dalwan01_at_[hidden]> writes:
>>
>> > Is there any interest for luabind in boost? It's similar to boost.python
>> > but generates binding code to Lua instead of Python.
>> >
>> > My feeling is that it would make a good package together with BPL.
>> >
>> > http://luabind.sourceforge.net
>> >
>> > (note that the library is still in beta)
>>
>>You might note http://aspn.activestate.com/ASPN/Mail/Message/1606964,
>>a message which I cc:'d you on an received no response to. At the
>>time I took it that you weren't interested.
>
> Hm.. Checked my inbox, I never got that message.
>
>>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?
> 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.
> Anyway, I am _very_ interested in this.
I'm very happy to pursue it with you.
-- Dave Abrahams Boost Consulting www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk