Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!att!news.cs.indiana.edu!samsung!olivea!uunet!arris!rshapiro
From: rshapiro@arris.com (Richard Shapiro)
Newsgroups: comp.lang.clos
Subject: Re: Beefs about CLOS
Message-ID: <1991Mar14.140906.6861@arris.com>
Date: 14 Mar 91 14:09:06 GMT
References: <91Mar13.134622est.133188@wotan.ai.toronto.edu>
Organization: ARRIS Pharmaceutical, Cambridge, MA
Lines: 64

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.


This seems like *better* (more coherent) modularity to me.  If you
want to advertise a generic function as part of a modular interface,
it must have a single lambda-list. Otherwise it isn't a (single)
generic function at all. If you truly need different arglists for
different methods, then what's wrong is not CLOS but rather your
programming decision to make a single generic function out of
disparate methods.

> 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++.

In this case, you should certainly be using different packages for the
two subsystems. I.e., there are actually two different generic
functions called LAYOUT, one in the GRAPHER package and one on the
DESIGNER package (package names chosen at random).


>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 see the problem here. Both methods take a single argument: one
takes an array, the other takes a list. Sounds like classic CLOS to me
:) 

>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.

As you develop a new system, you may indeed need to add new arguments
to an existing generic function (just as you might need to add new
arguments to a conventional function). In this case, you should either
add those arguments to each method; or you should decide that you no
longer have one generic function, and you rename one of them. All
sorts of things can change when you're prototyping: class definitions,
arglists, packages, etc. There's nothing special about changing the
lambda list of a generic function.

>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.

CLOS allows arbitrary keywords in INITIALIZE-INSTANCE methods. This
should solve your problem.