Re: Registries

Daniel Wallin <[email protected]> writes:

> At 19:07 2003-07-13, David Abrahams wrote:
>>Daniel Wallin <[email protected]> writes:
>> > 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!
>
> By "tuple assignment" you mean multiple return values? 

Yep.

> It can be quite convenient sometimes to not have arity checking
> there, although I agree that it can result in coding errors getting
> passed by.  I agree with your other rants, global default in
> particular is disturbing.
>
>>[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
>>]
>
> It should be "table.getn".
>
>     > ./lua
>     Lua 5.0  Copyright (C) 1994-2003 Tecgraf, PUC-Rio
>     > print(table.getn)
>     function: 0xa042350
>
>>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?
>
> Well, lua isn't as complex as python so it isn't that hard learning
> it

Python is really simple to learn.

> so I guess you just read the reference manual and learn by
> trying. :)

Fun, fun!

>> > 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.
>
> Me too, but in my second post I for some reason decided to confuse
> you by writing 'code' instead of 'graphs'. :)
>
>>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.
>
> Why? Do you mean because of type_info::name() comparing?

Well, yeah, or type_info comparing, depending on how cooperative the
native support for RTTI across shared libs is.

> In that case we have the same problem of unique ID's with
> the conversion registry as well.

I don't think I understand what you're saying here.

>>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?"
>
> If the problem is the unique id's; do we really need to care about
> it?

No, the problem is patterns of converter lookup and common registry
data.  Consider the scoped lookup already being proposed: first we
look for converters in the current module, then in its parent, then
in its parent, ... 

Now I get an extension module from a library vendor, who publishes the
definition of some C++ types, and I want to write another extension
module which manipulates those types.  What do I write in my code to
say that's what I want?  What is the resulting lookup pattern?  What
happens in the case of generalized interaction graphs?  Suppose I get
extension modules A and B from two different vendors, and I want to
interact with both of them, but I don't want that to interfere with
the operation of A and/or B (i.e. A/B shouldn't be forced to share
data)?

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