OpenEuphoria

Re: Euphoria Standard Library on UBoard

• Posted by Derek Parnell <ddparnell at bigpond.com> Jul 29, 2005
• 543 views

Robert Craig wrote:
> 
> irv mullins wrote:
> > &gen
> > Bernie Ryan wrote:
> > > 
> > > I been using Euphoria for over 5 years and have had to use
> > > different names for my routines many times. I have respected
> > > other users names and have had to use a different name.
> > > I think that you will find that is why derrek started his
> > > his present naming convention in the win32lib. When you and
> > > and jason have written a lots of code to contribute to
> > > the archive you will understand why it's not easy to come up
> > > with different names and then to have to change them.
> > > Why don't you prefix your routines as derrek does ?
> > 
> > Instead of asking all Euphoria users to 'prefix their routines', 
> > why not ask RDS to improve namespacing so this isn't a problem?
> > 
> > Oh, nevermind. I guess I know the answer.
> 
> The Euphoria namespace feature does precisely what
> is required in this situation. It gives you a way to specify
> which global symbol you are referencing, in a situation where
> there are multiple included files (usually by different authors)
> that coincidentally contain symbols with the same name.
>  
> Regards,
>    Rob Craig

Robert, I'm going to sound rude here, so please forgive me. But are you just not
listening to us?????? A number of times you have been told about the problem with
namespaces.

I repeat it yet again.

Here are five files. Please create them your self to see the effect.

-- file_a.e --
-- Author: Alice
global constant ABC = 1
-- end file_a.e --


-- file_b.e --
-- Author: Bob
include file_a.e  -- Use alice's library.
global function B(integer x)
   if x = ABC then
      return 2
   end if
   return 0
end function
-- end file_b.e --


-- file_c.ex --
-- Author: Carl
include file_b.e -- Use bob's library.
? B(3)
-- end file_c.ex --

Up to this point we have no issues. Now Carl wishes to use Eric's library too.
So file_c.ex gets updated to ...

-- file_c.ex --
-- Author: Carl
include file_b.e -- Use bob's library.
include file_e.e -- Use eric's library
? B(3)
? E(3)
-- end file_c.ex --

And eric's library looks like this ...

-- file_e.e --
-- Author: Eric
include file_d.e -- Use Daphne's library
global function E(integer x)
   return x >= ABC()
end function
-- end file_e.ex --

-- file_d.e --
-- Author: Daphne
global function ABC()
   if platform = 1 then
      return 0
   else
      return 4
   end if
end function
-- end file_d.e --

Now all of sudden, we see errors happening. But not in Carl's program but in
Eric's library!
Carl's program doesn't even use the ambiguous symbol causing the error. The only
way to 'fix' this is to have Carl go an change the source code of someone else's
library - assuming he has the clear-text source. And then repeat for every new
release of that library.

Euphoria should not be forcing me to change somebody else's code. Okay, so the
library writers could have used namepsaces and prefixed *EVERY* reference to a
global symbol with the respective namespace prefix. But how is that a labor
saving device? It is no better than hardcoding a prefix.

The best solution for your customers, would be to only scan through the include
tree that you are in. In other words, Eric's library knows nothing of Alice's
library and only of Daphne's, and likewise Bob's library knows nothing of
Daphne's and only of Alice's. So instead of lumping all the globals into the same
pot, just have Eric's code scan through the libraries it includes, and the same
with Bob's library. It just makes sense that way.

A coder should only have to use namespaces to resolve identifiers that they
actually use. If Carl had referenced 'ABC' in his code then he would need to
explcitly include the library that declares 'ABC' and use a namespace. This is
quite legitimate because it he only edits his own code and not somebody else's.

Don't you agree that a good programming language should be useful? Euphoria is
mostly useful, except for some really obvious areas that you can easily fix. And
this namespace issue is one of those low-hanging fruit.

-- 
Derek Parnell
Melbourne, Australia
Skype name: derek.j.parnell