🚀 go-pugleaf

From article <GUMBY.90Nov15080506@Cygnus.COM>, by gumby@Cygnus.COM (David Vinayak Wallace):
> 
>    Date: 15 Nov 90 10:18:47 GMT
>    From: marquard@rimfaxe.diku.dk (Morten Marquard)
> 
>    In "normal" object-oriented languages (SmallTalk, C++) an object can
>    exist alone. An object consist of a state and a set of methods, and
>    only the methods can change the state of the object.
> 
>    In CLOS an object can be changed by a generic function, in spite of
>    the fact that the object does not "own" the generic function, eq. a
>    generic function can change the state of an object, without the object
>    itself knowing it is has been changed!
> 
> Could you please rephrase your question?  What does it mean to "own" a
> method?  The actual method invoked by a generic function may be found
> due to some search, but that is no different than the case of the
> languages you cite.  The method ultimately selected still must have
> been defined for the class or one of its parents.
> 
> If you mean that handlers are not all declared or defined lexically
> within the definition of some class, well, personally I consider that
> an advantage, but there are people (and languages) that can make a
> strong argument that it's a bad idea.
> 
> 					  I have diskussed this with
>    others, and a lot of people do not view CLOS as an object-oriented
>    language.
> 
> It's ironic that an arriviste language like C++ is considered
> "normal."


i think you are right about c++...

but i think the original poster is right to raise the issue about
"owning" methods. in clos, all the arguments to a generic function
determine what version of the function is going to be applicable. 
in more restrictive langues (like smalltalk of loops) only the first
arguement (the object arguemnt) determines which version to use. 
and that allows one to think of a class as owning (or inheriting
in a straight forward way) a method. 

the real difference is the programing model that is being used in the
two different viewpoints. in CLOS, the model does not really include
the notion of an object "owning" a method, but in loops especially,
that is the way that programming tend to view the world. 

the result is that in CLOS there is a lot more flexibity/power, but
in LOOPS (and other languages of the same ilk) there is a strong 
sense of a object centered programming paradigm. so the trade off is
more power for a harder to manage (and esp to learn) programming world
view.

its interesting to note that when CLOS was first going around, being
dreamed up, et al, that it was touted as an "implimentation language"
in which other OOP langues could be built. Ie, LOOPS, FLAVORS, et al
would be reimplimented in CLOS via their individual meta level protocols.
that does not seem to be happening...

	---jon---