OpenEuphoria

Re: Namespaces

• Posted by Al Getz <Xaxo at aol.com> Jun 07, 2004
• 571 views

Hi pete,

Yes, it makes a lot of sense, but you have to realize that
that is not the only way of looking at the problem.  You're
sort of saying that there's only one way it can be.

Let's start over for a second here...

I'll use NSQ as a shortie for "Name Space Qualifier"...

Start of story...

Apparently, we want to be able to refer to a function without
an NSQ and mean to call the only said named function
that never got an NSQ, even though there are other functions
with the same name that had been declared with other NSQ's.

...End of story.

Now the question is not whether it can be done or not,
but how hard it would be to do.  I guess you could weigh
the difficulty of coding it in somewhere, but that's 
still secondary.

I'm 'sort of' satisfied with the way it is now, but it would be
better if libraries that depend highly on NSQ's could co-exist
nicely with libraries that dont use them at all, without any
modifications to either library.

Since we are on the subject  i might as well bring up the
'second instance' problem too.  You can't include a second
instance of an include file, and that's a shame too.  If you 
could, you could declare whole files of objects to be used
again with the same properties as the original (and hard work'ed)
file.  Currently, you have to rename the file first (!?!)....
<Sound(Qubert Drop)>

Im sure i've just touched the surface on these issues.

Take care,
Al

Pete Lomax wrote:
> 
> On Sun, 06 Jun 2004 07:54:44 -0700, irv mullins
> <guest at RapidEuphoria.com> wrote:
> 
> >Why is this? Logically, there should now be two functions visible to 
> >my main program (test.exu), one named two:foo()
> >and another function named just foo().
> 
> I'm sure this isn't the shortest answer you'll get, but:
> 
> You have two functions named foo(), one of which can be qualified
> using the namespace "two". There is nothing actually named
> "two:foo()", eg if you include misc.e as something, you can still call
> reverse(), you don't have to call "something:reverse()" [unless of
> course reverse() is defined somewhere else]. Clearly that can save
> alot of editing when there is only one conflict over a single name,
> not everything in the included file(s).
> 
> Suppose you have a source, say customers.e, which contains add(),
> delete(), and update() routines, and you write some code which calls
> them and test it.
> 
> You also create a file orders.e which contains the same named
> routines, but obviously they affect a different file or something, and
> again you write some code which calls them and test it.
> 
> (It might make a bit more sense to think of third party routines or an
> application written by more than one programmer).
> 
> Now you add them both to your main application, and of course you get
> a 'namespace qualifier required' on the first add() call (say). So you
> fix it, probably sensibly performing a global search for add(), and
> run the program again. If it worked the way you suggest, the program
> will compile cleanly, but, whichever way you went, half of the
> delete() and update() calls would be to the wrong one, and there would
> be no further error or warning messages to help you.
> 
> If the interpreter assumed no namespace means the first include (ie
> the one with no "as" clause), then after one warning, you would have
> to perform a global search on every global in the source you added a
> namespace qualifier to, plus any further code you add will not give an
> error if you forget to specify the namespace when you should have.
> 
> Does that make sense?
> 
> Regards,
> Pete
> 
> 


Good luck with your programming!