The problem discussed on this thread has been discussed during the Dylan
design, as has the particular suggestion of using a naming convention.
This particular solution was rejected, and the problem was generally "un-asked"
as being a unexamined carry-over from languages where slots, fields, whatever
do have magic treatment and a special namespace.
The relevant part of the Dylan design philosophy is that:
Slot access is exactly the same as function call, and that is a Good Thing.
The theory is that it is wrong to think of some operations on objects as being
"slot-like" and others as being derived. Many languages force you to make that
distinction, but there isn't any good justification of why this should be so.
Note that Dylan's use of the multi-method/generic-function OOP model eliminates
of major reasons for wanting to make slots different from global variables. In
languages where methods are "owned" by a single class, it makes sense for those
methods to have special access to that class's slots (thus a class doubles as a
namespace.)
In Dylan classes are not namespaces; access is controlled by the module system.
Programmers used to C++, Smalltalk, etc., may take a while to realize how
useful a separate namespace control mechanism can be.
So I think that the one-namespace approach to slot accessors makes good sense.
There is nonetheless a code-style problem, since people will tend to want to
use the "a.b" notation with terse slot names (as they would in other languages
with the dot notation.)
All I can say is that the problem of slot-accessor collisions must be kept
under control in the same way as any other variable name collisions: by using
adequately specific names and by use of the module system.
One must also resist the temptation to "pun" generic functions by spuriously
combining different functionality under one generic function simply because the
same name is convenient. Dylan discourages this by its method congruence rules
and by allowing GF type declarations.
Rob
|