#74 Naming convention for Logolib procs to reduce name clash

[Erich Neuwirth]

I just stumbled upon something. Doing a class about sorting, I defined a function sort.merge.
This already is a buried function in the sort library procedure file. So things work with the new definition,
but the new function is not listed.
Therefore I suggest to change the contents of the sort library file.
I changed every name of the form sort.xxx
to sort.lib.xxx
I think this way name clashes are much less likely.

[Erich Neuwirth]

sort library file with changes

[David Costanzo]

Good point. I've been very hesitant to add new primitives for fear of breaking backward compatibility with programs/libraries that happened to that name for their own procedure. I had thought that adding new Logolib routines was generally safe until someone complained about a "hiding" problem on non-English builds (see bug #2335263). In theory, using the name of the new library procedure as the prefix of all helper procedures/variables was supposed to prevent clashes, but I guess it doesn't eliminate the possibility.

Instead of using "sort.lib." as the prefix, I think I'm going to define a prefix that FMSlogo owns. Something like ".fmslogo.sort.merge" This way I can give some clear guidance to library writers: don't start any procedure or variable name with ".fmslogo".

I expect to do this for SORT before the next minor release. I'm not sure when I'll get around to doing it for the rest of the Logolib routines.

[David Costanzo]

I have moved all procedures and variables for SORT to begin with ".fmslogo.sort", similar to the file that Erich uploaded. This will be included in FMSLogo 6.24.0, which I expect will be released sometime in May 2009.

Instead of closing this feature request, I have re-purposed it to include all Logolib routines.

[Erich Neuwirth]

The documentation in some places contains the following

WARNING: Primitives whose names start with a period are dangerous. Their use by non-experts is not recommended. The use of .SETFIRST can lead to circular list structures, which will get some primitives into infinite loops; unexpected changes to other data structures that share storage with the list being modified; and the permanent loss of memory if a circular structure is released.

Therefore anything with an initial period in the name is slightly incompatible
with the usual UCBLogo conventions.
Just using fmslogo.lib. as the prefix could achieve the same goal without
getting into a conflict with this conventions.

[David Costanzo]

That convention is part of why I chose ".fmslogo" as the prefix, instead of "fmslogo". I don't see any conflicts with this choice. Instead, I see this as a logical and consistent extension of the convention.

I think of it like this:

* Procedures that being with a dot are for experts only.
* Primitives that begin with a dot can cause FMSLogo to crash.
* Library routines that begin with a dot are not documented and subject to change without notice.