This is the mail archive of the guile@cygnus.com mailing list for the guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: setf.scm


>>>>> "Per" == Per Bothner <bothner@cygnus.com> writes:

Per> I understand how to model single-dispatch in a state-less manner:
Per> An object has a bunch of fields and methods associated with it.
Per> The association is created when the object is created - i.e.
Per> there is no need for side-effects to understand or implement this.
Per> Calling a method is just a matter of selecting the right method
Per> from the object using a key given by the call.
Per> I can add a new class to a running system without changing any
Per> of the objects (classes or instances) already existing.

But is not different in CLOS. Adding a new class doesn't in itself
change how other classes or instances work (except if you are
redefining a class, but this is not the issue here?).

It is true that you get global changes by adding a new method to a
generic function, but I do not see this as any different if methods
was stored inside classes. If you add a new method to a class object,
thus changing its method table, then the associated generic function
would (globally) change its behaviour.

I cannot see that the effects of manipulating the method table is
fundamentally different whether this is stored inside the generic
function object or inside the class object.

The main difference between the two situations is (I think) what the
key of the tables are. With CLOS' generic functions (single- or multi-
dispatch), the combined method lookup table is stored in the gf object
keyed by object class (so to speak), whereas it with class association
can be thought as individual tables keyed by gf name instead. 

But with inheritance, a particular gf still sees the combination of
all tables in all the relevant classes, such that manipulating the
table of one class (potentially) changes the globally visible
effective combination and thus also affects the gf.

Perhaps it can be argued that collecting the method lookup table in
one particular spot (the gf) rather than distributing it across the
class precedence list is somehow more dangerous, but I do not see the
latter as removing the fundamental problem of manipulating the
(effective) class to method mapping having global effects on generic
functions.


---------------------------+--------------------------------------------------
Christian Lynbech          | Telebit Communications A/S                       
Fax:   +45 8628 8186       | Fabrik 11, DK-8260 Viby J
Phone: +45 8628 8177 + 28  | email: chl@tbit.dk --- URL: http://www.telebit.dk
---------------------------+--------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
                                        - petonic@hal.com (Michael A. Petonic)