[Date Prev] [Date Next] [Thread Prev] [Thread Next] Date Index Thread Index Search archive:
Date:Mon Jun 25 02:55:31 1994 
Subject:Re: Name Space Pollution 
From:Luc Beaudoin 
Volume-ID:940626.01 

Patrick C. Beard <beard@cs.ucdavis.edu> writes:

> Article: 2210 in comp.lang.dylan
                             ^^^^^
[By creating a new class with x,y,z as slots]
>  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:  how should I name slots so that I don't end up generating
>  easily destroyable getter/setter generic functions? This isn't a problem with
>  other slot based languages. For example, in NewtonScript, if I create a slot
>  in a frame, a global identifier doesn't come into existence with the name of that
>  slot.
....

> Am I just imagining this problem? I've already run across it in my work with
> Marlais.

Sounds like a problem with Dylan to me. A better approach is taken
in Poplog Pop-11's (a dynamic language similar in philosophy to
Dylan) main object oriented system, Objectclass, which protects
slots so that they can't be overwritten (it also  declares the
function as a Pop-11 procedure, which further prevents the user from
assigning a non-procedure to the name). I think the same protection
should be granted to all Objectclass generic functions (slots being
a special case). Of course, Pop allows protection to be overriden if
a user really intends this (e.g., by using "syscancel").

Objectclass also offers useful protection in the other direction, so
that if there is a dynamic identifier that has the same name as a
function one is currently defining, then OC prints out:

;;; WARNING - PREVIOUS VALUE WAS NOT A METHOD

(Warnings can be turned off.)

If there really is a user demand for the way Dylan currently
proceeds, perhaps Dylan should provide a switch so that users' can
control whether by default function names are protected or not.

Luc
--
--
Luc Beaudoin                          |  School of Computer Science
E-mail: L.P.Beaudoin@cs.bham.ac.uk    |  University of Birmingham
beaudoin@mach00.scs.carleton.ca       |  Birmingham B15 2TT, UK