Re: Registries

At 19:23 2003-07-14, David Abrahams wrote:
>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.
> >>
> >>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.

Yeah I know, but still, it's far more complex than lua.

> >> > 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.

I'm saying that this has very little to do with people sticking everything 
in the
global namespace, and more to do with our inability to generate unique id's
for types. We would only need different cast-graphs if there are type id 
conflicts,
just like we need to isolate the conversion registries if there are conflicts.
Or am I missing something?

> >>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)?

Right. I don't have any answers to those, it all seems really complicated and
I can't really see any clever solutions to any of it.

---
Daniel Wallin



-------------------------------------------------------
This SF.Net email sponsored by: Parasoft
Error proof Web apps, automate testing & more.
Download & eval WebKing and get a free book.
www.parasoft.com/bulletproofapps1