Re: symbol resolution (was:EuCOM : Attn Matt : String Return Value)
CChris wrote:
>
> I have thought a fair deal about this, and what I have been readingmakes my
> earlier point even clearer: tinkering with namespaces cannot solve the problem
> of having several multifile libraries play together without modifying any of
> them.
> You need a _different_ concept, which is one of a _set_ of files being
> collectively
> grouped together. Namespaces apply to only one file, with or without
> inheritance.
It's still not clear to me why we need a different concept, rather than a
more comprehensive implementation. Also, I think the concept of a namespace
being able to reach into the includes of a particular file makes a lot of
sense. For instance, you can use a single namespace for any function that
is part of win32lib. Then, the user doesn't have to be aware of the
implementation details--just that he uses stuff from win32lib.
> In order for applications to use any combinations of libraries and to be
> immune
> to any change in their inner working, subdirectory layout and whatnot, you'll
> have to make explicit the distinction between an interface symbol - which is
> meant to be available everywhere, except if explicitly shadowed - and a
> multifile
> symbol, which is meant only to be seen from a specific set of files. For
> historical
> reasons, the two are currently defined as "global": this makes the proper
> handling
> of current code more complex.
Please provide some evidence (or at least an example) of why we need an
explicit distinction between the interface symbol and a multifile symbol.
The only advantage I see is encapsulation. That's a good thing to have,
but it doesn't really solve any of the symbol resolution issues. Sure,
you may have reduced the scope of the problem, since there are simply
fewer symbols floating around and able to conflict, but it only takes
one to generate an error or a bug.
> I still consider the kind of proposal I had put forward before as more
> relevant
> than a simple change in namespace semantics, which is not solving the
> problems,
> or replaces them with others, as the recent posts show.
Well, the "new problems" are just an artifact of thinking through the
consequences. And I suspect that the implementation is much less complex
than what you've proposed. Can you please present an example of how your
solution solves something that mine does not?
> See http://oedoc.free.fr/Packages.htm for
> a complete description. I have a working copy of eu.ex using this scheme. One
> could remove
> the "with previous_package" directive, at the expense of a little more file
> splitting,
> as symbols of different packaging status should have to go to different files
> then.
>
> I'll emphasize again that the dual export list mechanism described there is
> meant as a _transitional_ feature, whose purpose is to allow immediate
> wrapping
> of existing code so that it works without clashes now, without having to wait
> for it being rewritten. This is why the scheme is far less complicated than
> it might seem to some.
It still seems overly complicated to me. I doubt I'll be convinced until
you can show me some advantages through examples. Or maybe we're really
talking about different issues. In which case I still find your proposal
over complicated.
Matt
|
Not Categorized, Please Help
|
|
