OpenEuphoria

Re: Namespace clobbering internals

• Posted by Shawn Pringle <shawn.pringle at gma?l.?om> May 01, 2008
• 780 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.
> 
> I think I am back to my original thoughts on this:
> 
> <a
> href="http://www.openeuphoria.org/EUforum/m20234.html">http://www.openeuphoria.org/EUforum/m20234.html</a>
> 
> 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.
> 
> 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? 
> 
> --
> Jeremy Cowgar
> <a href="http://jeremy.cowgar.com">http://jeremy.cowgar.com</a>

Consider this:
(eu.e:)
global procedure old_close( integer fd )
    close( fd )
end procedure

global procedure close( integer fd )
    close( fd )
end procedure

global function open( sequence filename, sequence access )
    open( filename, access )
end function

----

main.ex
include eu.e as eu
include db.e as db
integer fd
object line
fd = eu:open( "c:\autoexec.bat", "r" )
line = gets(fd)
while sequence(line)
  ? line
  line = gets(fd)
end while
old_close( fd )


You see you can setup a builtin namespace without touching the backend source.
You can still access the builtin but you have to alter how you access it.  This
would break any large project: win32lib.ew, ide.exw and thus inhibit the 
standard library's acceptance to large existing projects.  This is what we did
for redefining printf().  Often the new printf would need to call the old printf
you needed to give the old printf another name: old_printf.

Shawn