[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Method Combination Objects
Date: 13 Jan 88 10:36 PST From: Danny Bobrow
I have no problem at all with the Method Combination
Object Layer. It seems just right.
Here is an alternative proposal for a "naming" layer.
(method-combination-instance g-fn name :options options)
is how a method combination name and options are converted
into an object.
This looks good to me except for two fairly minor points. One
is that I think the options should be a required argument rather
than a keyword argument. There is no reason ever to omit this.
Fine with me.
Secondly, I'm not sure about the name method-combination-instance;
it doesn't seem consistent with the rest of chapter 3. I don't
know if you've changed the naming conventions since the last
version I saw, but in that version the consistent name would be
something like expand-method-combination. Personally I prefer
parse-xxx for names of functions that convert specifications into
objects, rather than expand-xxx.
I saw method-combination-instance as being parallel with the generic
function slot-description-class, since both participate in the creation
of "secondary" objects, i.e. slot-descriptions associated with a class,
and method-combination-objects associated with a generic function.
Hence the name.
In recent days Gregor has come to believe that we need not specify any
of the expand-xxx objects which are macroexpander helpers. He claims
that to change the macroexpansions users "should" write there own
macros. What is your feeling about these expand-xxx or parse-xxx
generic functions (I have become neutral on them).
Let me know what name is consistent with what you're doing and
I'll mail out a modified proposal when I get a chance.