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] |
>>>>> "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)