OpenEuphoria

2. Re: Coding Conflicts in FileList.e & Ed.ex

• Posted by Robert Craig <72614.1667 at COMPUSERVE.COM> Oct 06, 1996
• 1792 views

Lucien T. Elliott writes:
> Unfortunately, i ran into another coding conflict immediately
> when i tried to integrate it into ED.EX.  ChooseFile() calls
> WILDCARD.E (is this jacques code or someone elses?).
> Wildcard.e attempts to redefine LOWER() function which
> is already defined in ED.EX  Upon closer examination, i find
> that there are several instances of this type of conflict in the
> include files from various Euphoria authors.

wildcard.e is a standard Euphoria include file. When wildcard.e
was first created (v1.3), ed.ex already had a lower() function.
I considered removing lower() from ed.ex and simply including
wildcard.e in ed.ex, but in order to save a tiny amount of
start-up time for ed (since it is used a lot), and to save a
tiny amount of memory, I decided just to leave lower() in ed.ex
and not include wildcard.e, since that would be the only
function that ed would need from wildcard.e.

> Problem:  in a nut shell, if we are to share code/functions
> and extend the euphoria language in the process, we should
> identify common function like UPPER, LOWER or LCASE,
> UCASE, MIN, MAX and many others.  Perhaps, develop a
> schema for naming project/program files, and include files.

So far my inclination has been to not define a whole bunch of
very simple functions and types that you could easily create
for yourself if you needed them. For example I could have made
a standard include file with standard types like "positive integer",
"character", etc., constants like TRUE and FALSE, and
simple functions like abs(), min(), max(), and maybe
reverse() (reverse the order of elements in a sequence).
I have preferred to keep the language
very minimal and avoid burdening you with dozens of extra names
to learn about and try to remember. Now, if someone else
wants to define a bunch of these things and share them that
would be fine, but I am still inclined not to enlarge the language
manual with lots of simple little routines that might take you
5 minutes to create for yourself it you needed one. Anyway the
one that I defined might not be exactly what you would want so
you wouldn't use it.

[By the way, I might eventually define a reverse() in ex.exe because
it would execute faster than a simple reverse() that you could write
for yourself in Euphoria. So far I haven't seen a lot of
examples where it would actually be necessary, since typically
all you need is to write a descending for-loop to access the
elements of a sequence in reverse order for some purpose.]

I'm very happy to see others creating and sharing generally-useful library
routines, conflicts or not. Here a few tips to promote "share-ability",
that are probably obvious to many people by now:

 * Only use the "global" keyword on those symbols that the
   user of your include file (library) is supposed to use.
   This way, the other routines/variables that you define will
   be "invisible" to your user's code and he will be able
   to use the same names without any conflict.

 * Don't make modified versions of the standard includes.
   Instead, put your code in your own new include file.

 * Avoid using symbol names (global or non-global) in your
   include files that are the same as any global symbols
   in any standard Euphoria include file, i.e. avoid
   using the names of any routines defined in
   library.doc. This way your users can include any of
   the standard includes along with your include file.

Note that if you are creating include files strictly for
your own use then you can obviously do whatever you want.
Feel free to modify any of the standard includes as
you wish. After all, they are Public Domain.

Remember that if you bind your program, it becomes a
stand-alone .exe that has no dependencies on any other
files, such as ex.exe or the standard includes in
euphoria\include. It is immune to any future changes in Euphoria.

All languages have potential naming conflict problems.
At least in Euphoria you have the source for the standard
libraries and you are free to modify it as necessary to
fix any conflicts.

Just some preliminary ideas.
Feel free to offer your suggestions.

Again, let me say that I'm very happy to see anybody
sharing their code, even if there are a few glitches.

     Rob Craig
     Rapid Deployment Software