Re: Method Combination Objects

[Danny Bobrow <Bobrow.pa@Xerox.COM>]

        Date: 13 Jan 88 10:36 PST From: Danny Bobrow
        <Bobrow.pa@Xerox.COM>

        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.


Thank you.