Re: symbol resolution (was:EuCOM : Attn Matt : String Return Value)
Matt Lewis wrote:
>
> CChris wrote:
> >
Sorry for the late reply, I have my hands full these days - moving within a few
weeks. All development/debugging activities are expected to be somewhat delayed
or disrupted during that period. Back to normal around end of november, hopefully
sooner.
> > 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.
Because sometimes you need to specify whether you need to access a particular
file or all the include subtree it is the root of. You'd expect applications to
use the second sort of access, but libraries may need the first kind, if only to
access shadowed symbols when extending them. Overloading namespacing is not
better than the current overloading of "global" - not worse admittedly.
> 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.
>
This is exactly what packages are for. As underlined above, using a namespace
for both file level and package level accesses isn't as safe as using two
different syntaxes.
> > 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.
I don't understand. If all libraries restrictively specify, for each non local
symbol they define, where it is to be seen from, then there is not a single
conflict left, except when two interface symbols collide. In this case (two
exported abs() functions), a simple addition or deletion from an export list at
the application level, or a simple scope restriction directive, will mask one of
the clashing symbols and solve the conflict.
> 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.
>
Other advantages - encapsulation is of course a powerful one already:
* When you read the code of a library, you'd know immediately whether a symbol
is for the lib's internal use or for the end user. Currently they both read
"global".
* Applications need not worry with undocumented symbols popping in to start a
clash when the version of a library it uses changes. Multifile symbols can freely
appear and disappear, change names, change types - an application need not be
affected by this, and will not if the symbols are properly marked as scope
restricted.
* By externally changing the status (true global vs multifile) of a routine, you
can extend it any number of times. Currently, you can extend builtin routines
only once and library routines zero times. For variables, this is less useful -
but should there be global variables at all?
All the above, when using the proper costructs, can be done without changing a
single line of existing code; a wrapper include file can handle it all.
> > 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?
I'll have to check the documentation at your branch. I think the wiki should
present globally how each and every kind of symbol clash will be handled or not,
rather than only mentioning the differences.
>
> > See <a
> > href="http://oedoc.free.fr/Packages.htm">http://oedoc.free.fr/Packages.htm</a>
> > for
> > a complete description. I have a working copy of eu.ex using this scheme.
> > One
> could remove</font></i>
> > 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.
> </font></i>
> >
> > 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
It looks like you are concerned with other types of clashs than I, but my
solution also handles "yours". Also, I may be more concerned about what happens
when a library changes: the issues are subtly different, since they concern code
you didn't write and ideally should not modify. I don't see that your solution
helps much there - again, I have to read a complete description.
CChris
CChris
|
Not Categorized, Please Help
|
|
