Thu, 20 Jul 1995 23:52:18 -0400 (EDT)
> > Having a generic function reifies (makes into an object) the dispatch
> > technique. This is good for reflexion because you can then observe,
> > modify and create new dispatch techniques.
> true. true. true.
> but how to find the function? where is it located? in what
> context/namespace? in an object, *dammit*.
The function could be the result of the application of some other function.
I don't see functions as belonging to any particular object. A function
is just another object.
> and since i found it in an
> object, i can save at least this one dispatch (if i already have the object
> and the compiler is smart enough to bind the call/send early).
> _that_ is what i am talking about.
I'm not sure what you are talking about but I'll make a guess because
the overhead for a clarification is pretty high.
You seem to say that since the function must be stored somewhere, we
can store it in one of the objects to which it is applied in order
to save dispatching on one of the arguments.
But that doesn't save any dispatch. Getting the generic function is not
the problem. We must have it before we can apply it. That work is
not part of the dipatch.
You then talk about the compiler knowing something at compile time ?
But this allows for some partial evaluation whether or not we use the
generic function model.
> > So I disagree that single argument dispatch is more efficient.
> efficiency in the single argument case depends on how many cases have to be
> checked. with generic functions it's the number of different types. with
> message passing, it's the number of attributes the object has.
I have never implemented generic method dispatch or message passing dispatch
but that's how I see it :
Time efficiency seems like the same to me, one table lookup. The index
is the type "number" in the first case and the attribute "number" in the
Space efficiency seems similar. N generic functions with M types or M
types with N attributes. Of course there is the problem of associating
small integers to each type in case #1 and each attribute in case #2
which leads to unused space in both cases if we use a simple scheme
(maybe more in case #1).
And what is to prevent the compiler from using the usual
implementation techinque of message passing (a table for each type and
an index for each attibute) to implement the special case of generic
function dispatch when it's favorable ? And vice versa... ?
I don't think efficiency favors message passing.
> in both
> cases, a dynamic compiler can cache the decision most of the time.
> > And chaining single arguement dispatches is a mess.
> no need to when "generic methods" exist.
I know of generic functions and methods (which are generic in a sense
although they don't do any dispatch). But I don't know of "generic methods".
How do they eliminate the need for chaining ?