Patrick C. Beard

define class <point> (<object>)
  slot x, type: <number>, init-value: 0, init- keyword: x:;
  slot y, type: <number>, init-value: 0, init- keyword: y:;
  slot z, type: <number>, init-value: 0, init- keyword: z:;
end class <point>;

Now, I've just generated 6 new generic functions: x, x-getter, y, y-getter, z, and z-getter. After this point, I can no longer safely use the identifiers x, y, z, etc. at top level or else I'll trash the generic functions.

My question is:

Rob MacLachlan

Generic function variables are "read only" in Dylan, so implementations would be strongly encouraged to complain if a generic function variable is clobbered.

I'd like to clarify that defined generic function variables are "read only" in the technical Dylan sense that you can't assign to them at run-time. This doesn't mean that you can't add new methods; method addition is restricted only be sealing and method congruence.

Note also that a "defined generic function" variable is not any old variable that happens to hold a generic function; I mean the GF variables defined by define class, define generic and define method.

Carl L. Gay

Coming from CLOS, it was a little confusing to me that in Dylan the slot names weren't necessarily specified in the slot specs (or anywhere else). That is, in the below "point-x" is not the slot name, it's just the getter name, but you really think of the slot as the "x" slot of the point.

define class <point> (<object>)
  slot point-x, type: <number>, init-value: 0, init- keyword: x:;
  slot point-y, type: <number>, init-value: 0, init- keyword: y:;
  slot point-z, type: <number>, init-value: 0, init- keyword: z:;
end class <point>;

I guess this makes sense in Dylan since the slot is only referenced through the getter and setter, and never by name is in with-slots in CLOS, so having to specify the slot name and the getter would be redundant.

Rob MacLachlan

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.

Andrew LM Shalit

(Rob MacLachlan)wrote:

>
> 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 "unasked" 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.
>
> [lots of good text deleted]

Exactly.