OpenEuphoria

Re: Packages

• Posted by Matt Lewis <matthewwalkerlewis at ?mail.c?m> Aug 07, 2007
• 557 views

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.

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

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.

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

As one of the people concerned, I'm against it.

Matt