OpenEuphoria

Re: Namespace clobbering internals

• Posted by Mike <vulcan at w?n.?o.nz> Apr 30, 2008
• 788 views

Jeremy Cowgar wrote:
> 
> I create a db.e file that defines the word close. I then:
> 
> }}}
<eucode>
> include db.e as d
> 
> --- do things
> f = open(filename, "w")
> 
> -- later
> close(f)
> </eucode>
{{{

> 
> It called the database's close function, not the internal. So, even if you use
> a namespace, your included files cannot define functions by the same name as
> an internal and you expect to continue to use an internal function?
> 
> --
> Jeremy Cowgar
> <a href="http://jeremy.cowgar.com">http://jeremy.cowgar.com</a>

Jeremy,

As far as I can tell, builtin routines are automatically in a global namespace.
Anything that goes there is immediately available to every bit of the rest of
the
program being parsed. At the end of parsing that namespace must be chock full.

A program may define a routine with the same name as that of a builtin. If the
routine
is also specified as 'global' it will replace the original one and so we end up
with
the problem you encountered here.

I solve this in orac in 2 ways:

1) Anything defined as 'global' will only reach to the next level and cannot
exceed that range unless propagated further. If there could be said to be global
namespace in Orac, it is superbly clean.

2) Use the prefix 'builtin' and the compiler will know that you only refer to
the builtin symbol.

In the code fragment above, the only change Orac needs for it to work correctly
is to drop the "as d" part. Your global "close" will override the builtin
"close"
until the end of that file, at which, time the builtin "close" will reassert
itself.

If you ever needed to access the builtin "close" inside that file then it is
just a case of..

builtin: close()

Well, I'm not sure that this actually helps you unless you convert to Orac
(Welcome to the Dark Side, brother, hehehe...).
No, seriously, since you've got work to do NOW, what I would do is just use
my_close.

regards,
Mike