john@LINUS.MITRE.ORG (03/16/91)
kramer@wotan.ai.toronto.edu ("Bryan M. Kramer") writes:
So in summary, my complaint is that the number of
number of required parameters has to be the same.
The problem seems to be that you are thinking of methods as analogous
to functions. They are not. A method is a PIECE of a function, a
generic function. In particular, it is NOT possible in CLOS to apply
a method object in isolation, via FUNCALL or APPLY.
So, you seem to want the generic function to take different numbers of
required arguments at different times. Huh? If they're different at
different times, then they're not always required. So, you want some
of the required arguments to be optional. But only sometimes.
Is this starting to sound somewhat problematic?
John Burgerandreasg@sigi.Colorado.EDU (Andreas Girgensohn) (03/17/91)
In article <9103151842.AA03261@clouseau.mitre.org> john@LINUS.MITRE.ORG writes: >kramer@wotan.ai.toronto.edu ("Bryan M. Kramer") writes: > > So in summary, my complaint is that the number of > number of required parameters has to be the same. > >The problem seems to be that you are thinking of methods as analogous >to functions. They are not. A method is a PIECE of a function, a >generic function. In particular, it is NOT possible in CLOS to apply >a method object in isolation, via FUNCALL or APPLY. > >So, you seem to want the generic function to take different numbers of >required arguments at different times. Huh? If they're different at >different times, then they're not always required. So, you want some >of the required arguments to be optional. But only sometimes. > >Is this starting to sound somewhat problematic? > >John Burger I would prefer that different methods of the same generic functions could have different numbers of required parameters. The selection of the applicable method(s) would depend on the number of parameter in addition to the types of the parameters. I would also like to be able to specialize optional parameters. This might produce some problems for the ordering of methods but only people who would have methods with different numbers of parameters would encounter these problems. I think that would have been a nice addition to CLOS that wouldn't have disturbed people who insist on congruent lambda lists at all (the CLOS implementors would have had more work). But I guess it is too late now, I can live with congruent lambda lists. Andreas Girgensohn andreasg@cs.colorado.edu
welch@CIS.OHIO-STATE.EDU (Arun Welch) (03/18/91)
[Our mailer died, here's a remailing of something that didn't make it through the gateway...arun] Date: 16 Mar 91 20:00:16 GMT From: andreasg@sigi.Colorado.EDU (Andreas Girgensohn) Organization: University of Colorado, Boulder Subject: Re: Beefs about lambda list congruency Message-Id: <1991Mar16.200016.24580@colorado.edu> References: <9103151842.AA03261@clouseau.mitre.org> To: commonloops@cis.ohio-state.edu In article <9103151842.AA03261@clouseau.mitre.org> john@LINUS.MITRE.ORG writes: >kramer@wotan.ai.toronto.edu ("Bryan M. Kramer") writes: > > So in summary, my complaint is that the number of > number of required parameters has to be the same. > >The problem seems to be that you are thinking of methods as analogous >to functions. They are not. A method is a PIECE of a function, a >generic function. In particular, it is NOT possible in CLOS to apply >a method object in isolation, via FUNCALL or APPLY. > >So, you seem to want the generic function to take different numbers of >required arguments at different times. Huh? If they're different at >different times, then they're not always required. So, you want some >of the required arguments to be optional. But only sometimes. > >Is this starting to sound somewhat problematic? > >John Burger I would prefer that different methods of the same generic functions could have different numbers of required parameters. The selection of the applicable method(s) would depend on the number of parameter in addition to the types of the parameters. I would also like to be able to specialize optional parameters. This might produce some problems for the ordering of methods but only people who would have methods with different numbers of parameters would encounter these problems. I think that would have been a nice addition to CLOS that wouldn't have disturbed people who insist on congruent lambda lists at all (the CLOS implementors would have had more work). But I guess it is too late now, I can live with congruent lambda lists. Andreas Girgensohn andreasg@cs.colorado.edu