In article <····················@SUMMER.SCRC.Symbolics.COM>, ···@stony-brook.scrc.symbolics.com (Scott McKay) writes:
>
> In my opinion, Barry is right in advising the you use the right tool for
> the job. If you have a primitive function like STRING-FOO, then it
> *should not* be a generic function for more than just performance
> reasons. STRING-FOO is intended *never* to be specialized by its very
> nature.
> ... Not all protocols are intended to be
> extensible, and using non-generic functions to ensure that they are not
> extended is entire appropriate. If I write a function called
> 3x3-MATRIX-MULTIPLY-INTERNAL, you can bet that I intended it to be used
> only for multiplying two 3x3 matrices, and that I don't want anyone to
> mess around with it by specializing it.
>
>
> ... I don't agree that the notion of
> reusability prohibits us from using non-generic functions.
"Right tool for the job" is the way to go, of course. As you said, if you
cannot subclass a class, it's good to have a non-generic function that takes care
of implementing a certain behavior. But there should also exist a generic interface
the functionality part of the exported protocol of the class, so when some method in
a superclass has to call it, it can do it through the gf. If you use a typecase in this
method in order to call the non-gf directly, when appropriate, you are effectively performing
your own dispatch, and I guess it should be better to let the compiler worry about optimizing it.
Also, if you define a subclass sibling of the non-subclassable class, such a typecase would not
make sense in the corresponding effective method code, and should be eliminated by the compiler.
Of course, when you know that an argument conforms to the non-subclassable class, it's great to be able
to call the non-gf. But, hey, I do not want the main part of the user's guide cluttered with descriptions
of functions like 3x3-MATRIX-MULTIPLY-INTERNAL. Leave it in the "advanced topics" section, and, please,
provide the gf interface, all those functions starting with the type name, really make CLIM (1.0, at least)
look like some old and heavy non-OO technology. The novice CLIM programmer has enough work trying to understand
output recording. Imagine a non-Lisp hacker! He might just put the manual next to his Occult Sciences books!!
(On the other hand, he will probably be so used to ugly non-OO or 00-like (X) interfaces, that he won't matter).
--
Fernando D. Mato Mira
Computer Graphics Lab "There is only one Language
Swiss Federal Institute of Technology and McCarthy is its prophet"
········@di.epfl.ch
FAX : +41 (21) 693 - 5328
Disclaimer:
disclaim([],[]).
disclaim([H|T],[DH,DT]) :- fixed_point_disclaimer(H,DH),
disclaim(T,DT).
fixed_point_disclaimer(Text,fixed_point_disclaimer(Text,_)).