Re: Registries

Daniel Wallin <[email protected]> writes:

> At 20:05 2003-07-12, David Abrahams wrote:
>>"Daniel Wallin" <[email protected]> writes:
>>
>> > In lua I think the most common usage is to just expose
>> > types/functions directly to the interpreter from your app.
>>
>>I'm not sure what that means.  Don't they have to be bound into some
>>module in order to be accessible from the interpreter?
>
> No, lua doesn't share python's concept of modules.

OK, downloading lua, reading docs...

Hmm, Lua is both cool (nice simple foundation, nice anonymous
functions,...) and deeply disturbing.

<rant>

The designers seem to have no problem letting coding errors pass
silently.  I can't believe they made global variables the default and
don't require an arity match for tuple assignment!  Ick, fully-closed
ranges in for loops and 1-based indexing (how is that good in a
language designed to interface with C/C++?)!  Ick, 'n' has special
status as a table key!

[and why can't I seem to call getn from the interactive interpreter?
    $ lua
    Lua 5.0  Copyright (C) 1994-2003 Tecgraf, PUC-Rio
    > print(getn)
    nil
]

Hmm, the first draft of "Programming in Lua" seems wildly outdated.
Maybe some of these problems are fixed?  No upvalues anymore, for
example!  How do you learn this language these days?

</rant>

>> >> * It seems to me that it might be desirable to be able to use
>> >> multiple language bindings in the same system (e.g. so people could
>> >> write interacting Python and lua extensions) but I can't really see
>> >> how that pans out.  I believe SWIG provides something like that,
>> >> but I don't know much about it.  Perhaps Dave Beazley wouild like
>> >> to comment?
>> >
>> > Would we automatically expose types/functions lua<->python?
>>
>>I don't know what that means.
>
> I'm not so sure either. :) I was thinking that we could
> automatically forward calls from one interpreter to the other, with
> some type of "bridge" functions.  

I don't know what that means either :(

>> > When using multiple language bindings in the same system, it's
>> > probably desirable to keep the cast-graph's separated.
>>
>>Why?  I can't see any good reason for that.
>
> You are right, there are no good reasons. I was confused.
> All inheritance code can be shared directly.

I was talking about the data structures.  Given peoples' tendency to
stick everything in the global namespace in C++, I guess we ought to
consider having a separate cast graph for each group of interacting
extension modules.  By "interacting" I mean that two extension modules
manipulate some of the same C++ types and use them in their function
interfaces.

One question I have is, "how does a user say that this extension
module interacts with these others, and what, precisely, does it mean
internally?"

> How do you feel about making the conversion registry into a template
> which is parameterized with a language descriptor?  

For some definition of "language descriptor", that's fine.  We might
want to stuff a lot of information into that descriptor.

> We could share a lot of code by doing that.

Agreed.


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