[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


> > ENVIRONMENT-PROPERTY env name property &optional default
> > 
> > This function and its SETF method allow the association of arbitrary 'global'
> > properties with names.  An environment can be thought of as having a local
> > property list associated with any name, and this function provides access to
> > that property list.  The association between names and property lists uses
> > EQUAL to match names. 
> I think this particular item needs more rationale to support it.  I
> gather that this is supposed to be the internal mechanism by which
> CLOS hangs information about the class structure off the environment?
> Why does this need to be generalized -- what is wrong with having
> FIND-CLASS be the primitive accessor for this kind of information?

There is precedent for this -- the MIT Lisp Machine system used by TI
and LMI provides a pair of functions called GETDECL and PUTDECL which
can be used to retrieve and store properties in the compile-time
environment.  The main difference is that the compiler environment is
implicit rather than being passed in as an argument.  I don't know how
many programmers actually use this feature, but since it needs to exist
for the compiler's own use, I don't see any harm in defining a standard
interface for it.