OpenEuphoria

Re: Do you currently use namespaces?

• Posted by CChris <christian.cuvier at agriculture.gou?.fr> May 27, 2008
• 997 views

Derek Parnell wrote:
> 
> CChris wrote:
> 
> >> Well why not make the default namespace the name of the file,
> >> without .e[??] at the end? 
> 
> 
> > For several reasons:
> > * mylib_v1.e may become mylib_v2.e
> > * file names may contain invalid characters for an Euphoria identifier,
> > including,
> > worst of all, spaces;
> > * What is the name of fileA.e under Windows? Its short 8.3 name? its
> > lowercased
> > form? its uppercased form?
> > * Having all of the above in mind, copy your library from one platform to
> > another,
> > and have fun.
> 
> OMG! These are problems that can never be solved in our lifetime. Let's all
> panic and run away now.
> 
> ... or ...
> 
> * Use the new v4.0 'namespace' directive to provide a default name for
> "mylib_v1.e"
> and thus also "mylib_v2.e"
> * Strip out illegal identifier characters
> * Convert to lowercase
> * As coded by the application author on the include statement
> * Huh??? What's the problem with different platforms and file names?
> 
> Come on Chris, try to help solve the issues. Please, we need all the good
> ideas
> we can get,
> 
> -- 
> Derek Parnell
> Melbourne, Australia
> Skype name: derek.j.parnell

That's why I don't think using a file name as default namespace is convenient,
and was stating it.

Actually, if we don't mind about existing code, using the new "internal" (or
whatnot) qualifier in conjunction with an explicit default namespace for files
that are part of the package is probably almost enough. With the addition of a
"restrict" directive like in "restrict gets from foobar to foobar", it would be
enough.

Now we have to ponder whether we want to keep in check pre 4.0 code with rogue
globals or not. That's why external exclude or include lists were designed for.
Also, the proposal I had made had provisions for being able to still use "global"
all around, and packaging directives like with package= would take care of
translating "global" to exported or internal. If converting to the new rules is a
light enough mental burden, then that component is not needed either. I actually
would feel relieved if the global (no pun) mindset has become such that we only
care for compatibiiity at a reasonable level. Good news.

What we may need is a clear statement on how transition is managed and whether
it ever will; this may be the tougher issue, but it wil impact what features or
changes 4.0 can take.

One thing though: can't logical packages be conntained in one another? There
would be missing a way to specify that a package belongs to another.
Perhaps

-- triangle.e
namespace geometry,math

 
is enough, the issue then being to enforce some consistency between the multiple
packages. Or we may not care anyway.

CChris