Re: setf.scm

[Christian Lynbech <chl@tbit.dk>]

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

Per> When object is created, it carries with it the set of modules
Per> visible at the creating point.  When a generic function is
Per> called, the applicable methods would be union of the methods
Per> belonging to the modules of each argument.

I like to think of a generic function as an object containing a set of
methods. Adding a new method just updates the contents of the
object. The module system thus would not interfere with the
dispatching: if you import the generic function (and thus the object)
you get all methods embedded in it.

Associating methods more directly with classes doesn't in my mind
change the situation. The method table would still be information
embedded inside the object as thus either is or isn't fully
accessible.

Your suggestion (as I understand it) would make generic functions act
more like a sort mini-obarray-namespace-restricting-kind-of-thing. The
gf looks a little like the module obarray in that "within" it, a
certain set of information is visible, all though rather than mapping
names to objects, the gf maps objects to methods.

I am not saying this is wrong, I would be curious to see what people
could out of that as well, I just think that for myself, this would
make generic functions too much of a hybrid between a function and
something else I do not quite know how to describe.


---------------------------+--------------------------------------------------
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)