Re: Do you currently use namespaces?
gshingles wrote:
>
> 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.
>
> 
>
> > 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?
>
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.
CChris
> 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
|
Not Categorized, Please Help
|
|
