Re: Do you currently use namespaces?

new topic     » goto parent     » topic index » view thread      » older message » newer message

Matt Lewis wrote:
> 
> This is one way to disambiguate.  I assume you're thinking of something like
> Java or perl, where file structure has meaning within the code.

blink

> It could still be a problem.  What if you're using two different libraries,
> each of which define a class with the same name?  For example, what if you
> have one library for using a database, and another for doing xslt stuff.
> It's pretty easy to imagine that both might have a Query class, for instance.
> 
> The bottom line is that you need some sort of container which is in the 
> control of the end user (at least, if you want *any* combination of 3rd
> party code to be usable together).  You can use file structure.  Euphoria
> doesn't use this.  It uses namespaces.

I think that's where Euphoria leaves the beaten track a bit.  Java and Perl are
good examples for your example above with having names like (for example)
MySQL::Query() or com.xxyyzz.xslt.Query().  No problem, except for the extra
typing involved, which personally I don't mind and each language provides means
to import those function names directly into your main namespace if you know
you'll rely heavily on them.

Even Python (from my all of two months experience with it) seems to 'namespace'
through levels of, shall we say, containment: os.path.join(...), string.join(...)
where they both behave differently.

The aim with Euphoria seems to be to bring everything up to the level of the
main program with the least amount of namespacing required, but to have the
facility available in case of conflicts.  This is fine by me, but I think this is
an opportunity to bring some level of modularity to the language that is
currently a bit 'loose', and I don't think it would break too much to implement
something at this stage (but that is obviously the target of your discussions on
the dev list which I haven't caught up on).

I saw mention of a default namespace being created by the coder of the include.
Well why not make the default namespace the name of the file, without .e[??] at
the end?  Even better, why not work out its path relative to the EUINC folder it
is in and make that the default namespace?  Even even better (all IMHO of course)
provide a function that returns the name (or numeric id) of that default
namespace?

From the one minute of thought I just gave to that scenario you'd have the
 start of a basic roll-your-own OO system, without inheritance and all that guff,
 since you could store instantiated data mapped to that namespace and pass around
 an instance id to your 'class' methods (ie global routines in the include)
 designed to use it.

I don't see how that would break anything since you could still use the
include..as mechanism, and any library taking advantage of the OOness would be
coded specifically to use that system (and be appropriately documented so).
Euphoria's type checking would even make it possible to do both, like Perl, a
procedural and an OO interface, it can even just be used as a default namespace
mechanism.

I'm happy to provide a comprehensive example of what I mean by all that if it is
seen as a good idea or needs clarification.  If it's not a good idea, I'd like to
know why? :)

Gary

new topic     » goto parent     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu