Re: Coding Conflicts in FileList.e & Ed.ex
- Posted by Robert Craig <72614.1667 at COMPUSERVE.COM> Oct 06, 1996
- 1828 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