I submitted the following to the tag group today via war### [at] tagpovrayorg:

Begin File
********************************************************************************
*                             Retroactive Aliasing:
  *
*         A Low Impact Method to Eliminate Identifier Name Collisions
  *
*                  within an Extended POV-Ray Includes Library
  *
********************************************************************************

Description of need:
    Until now, the avoidance of identifier name collision in POV-Ray script-
writing has been solely the responsibility of the authors of the scene
files.
This may need to change, however, since the POV-Ray community has recently
expressed an interest in creating an extended library of include files.
    Once the users of POV-Ray have such a library at their disposal, then it
is
forseeable that new include files will be written that will in turn include
previously written include files.  The potential combinations of include
files
in the formation of new ones is as completely unpredictable as the
imaginations
of the POV-Ray community.  Therefore, in order to make such a library a
reality,
it is necessary to establish a means for avoiding unforeseeable identifier
name
collisions.

Prior use and legacy:
    POV-Ray script is a descriptive language.  Although it has some
functionality which makes it seem like a programming language - such as
loops,
functions and variables - it is important to remember that it is not one.
Many
POV-Ray users are not programmers.  If POV-Ray were to adopt a method of
namespace management similar to that of a programming language (such as
Perl's
use of modules), then the users of POV-Ray might be required to radically
change the way in which they use POV-Ray as a condition to having use of the
extended library.
    Authors of POV-Ray scenes are accustomed to managing the names of
identifiers when they include files with known contents.  If two files
included
into the same scene file happen to each have an identifier by the same name,
then the author has options:  A) S/he can choose the order in which each
file is
included.  B) S/he can protect one of the named items by declaring it as
something else before including the second file.  C) S/he can edit the scene
file or one of the include files.  Until now, users of POV-Ray have enjoyed
broad freedom in the naming of original macros and objects.
    From the user's standpoint, the easiest transition into using POV-Ray
with
an extended includes library would be to treat any included file the same
way as
any other, without regard for the identifiers named in any indirectly
included
(i.e. inherited) file.

Description of remedy - Retroactive Aliasing:
    Scenario 1:
    If no method of identifier name management is provided, then a user
would
need to trace each include thread back to its source - reading every file
along
the way - in order to avoid name collisions.  This method would put the
highest
level of responsibility upon the user.
    Scenario 2:
    A conventional method of identifier name management is aliasing, whereby
users would have to rename identifiers - typically with prefixes.  If
POV-Ray
were to adopt this method, additional syntax would be required from its
users,
increasing the users' responsibility in avoiding name collisions.
    Scenario 3:
    A third method - called "retroactive aliasing" - would not increase the
POV-Ray users' responsibility at all.  Retroactive aliasing is the complete
inverse of the first scenario.  The principle behind this method is to give
the
end-user the broadest freedom possible in the naming of identifiers while
putting the greatest limitation on the names assigned to preexisting
identifiers.  No aliases would be given to identifiers declared in the
user's
scene file.  Nor would they be given to any declared in any files included
directly by the scene file.  Aliasing would be applied to all identifiers
declared in all included files which are not also directly included by the
scene
file.
    What makes this possible is the fact that, even given their broad
freedom,
users have only sixty-three characters at their disposal when naming
identifiers.
The one-byte numerical values (ascii values) of these characters, as well as
those of the special characters used in POV-Ray script, are all below 128.
That
leaves the character values of 128 through 255 as an available resource for
the
assignment of non-conflicting aliases.  [Note: Use of utf8 not addressed
here.]

Implementation:
End File

[Note: For easier reading, copy and paste and view @ 80 columns.]

-Randall

Post a reply to this message