Re: Packages
Matt Lewis wrote:
>
> CChris wrote:
> >
> >
> > This had been discussed at length in the OpenEu group as well as on EuForum.
> > This algorithm may be good as long as the shape of the include tree doesn't
> > change. If it does, strange bugs may arise. Look to Irv Mullins' posts about
> > this issue, in 2004 I believe.
>
> This doesn't address the issue of paths and include files. It's a completely
> different problem.
Not sure; I'd have to see a more detailed proposal to tell.
>
> > If the main source file defines a global symbol that conflicts with one in
> > the
> > libs, and another file tries to use this symbol, you'll still have a ame
> > clash.
>
> This is too vague for me to interpret, so I'll assume that you mean that there
> are two, conflicting symbols in the legitimate "include path" of a file.
> Yes, those symbols will conflict. This is the point of namespaces.
>
No, unless you count the main app file as part of the tree, which is true
somehow.
Application A includes a library L which has an internal global symbol. A
doesn't need to know about it, and the symbol is undocumented anyway since it is
not intended for public use. Yet, if A tries to define a global symbol of the
same name, then:
* calls from inside A.e will work, since this symbol will have highest priority
under current rules.
* calls from a file included by A.e, but unrelated to L, will fail.
And, since the symbol is internal to L, there shouldn't be any need for any
namespace qualifier. The symbol may pop in or out from one version of L to the
next.
> The problem is when, say, Jason uses one of my libraries, and he uses one of
> yours. Individually, they're both fine, but once he includes both, it
> breaks. *His* code should have to use namespaces. That is the whole point.
> The problem that this solves is that neither my library nor your library
> will break because they're both being used. The interpreter will be able
> to tell which symbol each library really wants, because presumably, neither
> library includes the other.
>
> > This solution, like import, which had been discussed a lot with different
> > names
> > like local_include, only addresses part of the larger picture.
>
> Yes, but I believe that it solves [at least] 95% of the larger picture,
> and does so in a transparent way that requires no changes to any existing
> code.
Mine doesn't require any - apart from the convenience exception for the standard
include files; but, as I emphaised in the paper, even that may be avoided.
What is the point of leaving 5% or 1% of the problem purposely unsolved? This I
fail to understand.
>
> > The supposed added complexity - two top level statements, two options to
> > with/without
> > and two keywords, to be precise - will concern very few people, namely the
> > writers
> > of multiple file libraries, who are the most exposed to the problems.
> > Otherwise,
> > exposure will be nonzero, but pretty minimal. Read the "Who is concerned..."
> > section of the paper. At least the whole problem would be addressed, not
> > just
> > some largish square in the middle of the picture.
>
> I don't completely agree with you. As I said, I think that you can solve the
> vast majority of the problem without adding any keywords or syntax. The
> difference between global and sort of global is just asking for bugs
> as everyone adjusts.
No, it _eliminates_ some bugs, since unexpected assignments are blocked.
And stating explicitly whether an interfile symbol is for public use or not
helps maintaining the code, doesn't it?
>
> As one of the people concerned, I'm against it.
>
Too bad.
CChris
> Matt
|
Not Categorized, Please Help
|
|
