Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!ub.d.umn.edu!cs.umn.edu!spool.mu.edu!think.com!barmar
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.lang.clos
Subject: Re: Beefs about CLOS
Message-ID: <1991Mar14.053206.11215@Think.COM>
Date: 14 Mar 91 05:32:06 GMT
References: <91Mar13.134622est.133188@wotan.ai.toronto.edu>
Sender: news@Think.COM
Organization: Thinking Machines Corporation, Cambridge MA, USA
Lines: 71

In article <91Mar13.134622est.133188@wotan.ai.toronto.edu> kramer@ai.toronto.edu ("Bryan M. Kramer") writes:
>1) Congruent lambda lists for generic functions. The
>main problem with this is that it seems to go against
>modularity in that the designer of a class has to make
>sure that no method names conflict with method names for
>other classes. For example, suppose one is working in
>an environment that contains graphical interface package
>with a class hierarchy for graphical objects that has
>a method called LAYOUT. Suppose now, that you are writing
>a system for chip design and decide the best name for
>a certain method here is also LAYOUT. Suddenly you have
>a name conflict that you wouldn't have had in LOOPS or
>C++.

Packages are intended to solve the problem of name conflicts across
unrelated programs.  The signature of GRAPHICS:LAYOUT doesn't have to
match the signature of CAD:LAYOUT.

Flavors also doesn't require congruent lambda lists.  The most annoying
feature of systems that don't make this requirement is that the programming
environment can't assist users.  In CLOS, one can write

	(arglist 'gen-func-name)

(on systems that have an ARGLIST function).

>A second problem with congruency arises when one would 
>like to write two different methods to perform the same
>function ... here one would like the same method name
>but different lambda lists. For example, a graph
>manager object might have two PLOT methods, one which
>accepts an array of x-y pairs and another which accepts
>a list of pairs ((x1 y1) (x2 y2) ...) as an argument.

I don't understand the problem here.  This sounds like:

(defmethod plot ((g graph) (points array))
  ...)
(defmethod plot ((g graph) (points cons))
  ...)
(defmethod plot ((g graph) (points null))
  ...)

>It also seems common to need to add parameters as one
>specializes methods ... this is practically a very useful
>capability although I can see theoretical arguments against
>it.
>
>Note that &optional or &keyword parameters don't fit the
>bill because one cannot specialize methods based on these
>parameters.

If the additional parameters are only useful when the earlier arguments are
of a particular class, the choice of method can be based only on the
earlier arguments, so you don't need to specialize on these.

>2) Custom arguments to INITIALIZE methods. I find that frequently
>that the values I would like to pass to make-instance to
>initialize an object are not values that I would like to
>store in slots.

Define an after-method on MAKE-INSTANCE.  Any keywords that this method
accepts are valid in a call to MAKE-INSTANCE of that class.  As you
mentioned, these arguments can't be specialized on, but you can call other
generic functions within the method that do.

--
Barry Margolin, Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar