Re: include statement bugs
- Posted by "Unkmar" <L3Euphoria at bellsouth.net> Oct 18, 2004
- 658 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