OpenEuphoria

Re: include statement bugs

• Posted by "Unkmar" <L3Euphoria at bellsouth.net> Oct 18, 2004
• 957 views

----- Original Message ----- 
From: "Igor Kachan" <kinz at peterlink.ru>
To: <EUforum at topica.com>
Sent: Monday, October 18, 2004 6:45 AM
Subject: Re: include statement bugs


> 
> 
> Chris Bensler & Irv Mullins wrote:
> 
> ----------
>> From: irv mullins <guest at RapidEuphoria.com>
>> To: EUforum at topica.com
>> Subject: RE: include statement bugs
>> Sent: 18 oct 2004 y. 6:31
>> 
>> posted by: irv mullins <irvm at ellijay.com>
>> 
>> Chris Bensler wrote:
>> 
>> > Is there anyone who agrees with how euphoria deals with duplicate 
>> > includes?
>> 
>> Since files of the same name in different directories are NOT considered 
>> the same file by any operating system I know of, why should Euphoria 
>> ignore the differences?
>> 
>> Irv
> 
> The Euphoria include files are too specialized, not usual, files.
> They are the libraries of functions, procedures and constants for
> the universal using.
> 
> Do you know any other programming language with the duplicate
> libraries names?
> 
> What a crazy fantasy to have duplicate names in different folders
> for the main programming stuff in Euphoria?
> 
> If you have such the duplicated names, it is just yours mistake,
> yours problem, yours bug -- nothing more.
> 
> Rename it and forget about that "problem".
> 
> It is not a Euphoria bug. It is a normal practice to have
> the different names for the different libraries.
> 
> Delete double - this is the most productive programming rule.
> 
> Regards,
> Igor Kachan
> kinz at peterlink.ru
> 

Another one blinded.

johnny/text.e
global function center(sequence data)
  -- fill in code
end function

alfred/text.e
global function justify(sequence text)
  -- fill in code
end function

Both libs have nothing in common and neither of them belong to me.
now, that is just a simple short example.  Not shrouded or anything like that.
but the problem goes much deeper because of collective libs.
Win32 is a collection of libs
kat has her collection of libs
I have mine. You may have yours.  We will likely duplicate names without
knowing it.  You may want to use others libs that clash.
1: Namespace clash - both libs have some routines named the same
2: Filenaming clash - both libs have have the same filename.
  Neither developer had any clue of the other and neither should have to
  give up their name.  A simple solution is.

unkmar/lib.e
scooby/lib.e
jami/lib.e
derek/lib.e
wingzero/lib.e
....

    unkmar