OpenEuphoria

Re: Namespace clobbering internals

• Posted by Matt Lewis <matthewwalkerlewis at gma?l.?om> May 01, 2008
• 749 views

Jeremy Cowgar wrote:
> 
> Jason Gade wrote:
> > 
> > Shawn Pringle wrote:
> > > 
> > > I saw the idea of keeping symbols out of the global scope necessary for 
> > > porting existing EUPHORIA applications and libraries to the new 
> > > standard library. Imagine you have 12,000 lines of code and you wish
> > > to use this new standard library.  Can you imagine having to do a
> > > search and replace for every builtin to include an eu: namespace
> > > qualifier?
> > 
> > But you wouldn't have to do that really (although automation certainly
> > eases the task). You would only have to add a namespace qualifier to
> > symbols that clashed.
> > 
> 
> I think Shawn is right. Say, you have your program that uses the function
> close() many times to close a file. Then you include, say, my pgsql.e file
> which also defines close(). 
> 
> Now, everywhere in his code that contains close() (as referring to the
> built-in close()), would require a prefix of eu: added. Otherwise, it
> would call the close() defined in pgsql.e, even though pgsql.e included
> inside of a namespace.

Well, remember, this is only if he wants to do add something new to his
existing 12KLOC.  If he keeps using the libraries he has, nothing changes.
How many built-ins are we talking about overriding?
 
> I think I am back to my original thoughts on this:
> 
> http://www.openeuphoria.org/EUforum/m20234.html
> 
> Now, Matt replied that it would break existing code, as people who have
> over-ridden built-in's intentionally to have their own version of printf()
> for use while debugging or something.

Yes.  But also consider your hypothetical pgsql.e.  It couldn't use its
own close() function, unless it defines a namespace for itself.  This
fails the principle of least surprise.

> Depending on how many people do that, it may just be better to realize
> that as soon as anyone anywhere defines a function by the name of an
> internal, then you've lost the ability to use that internal (as soon as
> you include that file in your code that is). That doesn't seem quite right,
> but that is how things are looking right now? 

I remain unconvinced that refactoring your code to accommodate a new 
library is too much of a burden.

Matt