Re: Philosophy and object systems (was Re: goops/guile doc)

[Craig Brozefsky <craig at red-bean dot com>]

Lalo Martins <lalo@webcom.com> writes:

> Hmm no, it has to do with the original concept of classes
> ``knowing how to perform operations themselves''. Has to do
> more with philosophy and terminology than technical matters.
> It's what I mean when I say ``tell the image to render on this
> surface'' rather than ``render this image on this surface''.

You might wanna check out:

http://www.cyberdyne-object-sys.com/oofaq/oo-faq-S-1.19.html#S-1.19

> Generics aren't a better sollution - or a worse one. They're
> different. A completely different approach. By 198x standards
> they wouldn't even be recognized as OOP ;-)

I would argue that they are the better solution, because they can
implement a message passing style, but are not strictly limited to
dispatching on one argument.  With a simple macro I can use generic
functions to implement something that looks and acts just like java
methods (except it would have consistent runtime semantics and allow
you to specialize on more than one argument, including "this"). I can
also implement abstract protocols that are not tied to any class, yet
still have all of the advantages of full polmorphism.

Being rather experienced with CLOS, as well as Java and ObjC, I can
say with some grounding that I dig generic functions with their
multi-polymorphism more than message passing with limited
polymorphism.  I also think encapsulation is overvalued, and don't
mind that mulit-methods do away with it, even finding it makes life
easier.  I know when I want to violate encapsulation and I don't need
no friggin compiler yapping like a stressed chihuaha at me when I
decide to do it.

Other advantages of multi-methods is you can define various types of
method combinations, not just a single type like most message passing
languages provide.  They also support languages that allow
redefinition at runtime easily, because there is not such a tie
between methods and class definition.

I suppose we should take it as a compliment tho that GOOPS is being
charged with not being retarded like most the other "OOP" languages
out there.  That sorry bunch of Platonic creoles people call OOPLs
aren't good for much more than banging together business objects and
writing the example video-store rental application in some Learn XXX
in 21 Days book.  The same thinking that brings us these so called
"original concepts of OOP" are talking about "Entity Beans" for
chrissakes.

Fuckin'A man, "Entity Beans".

We won't even get into the way that the Class designing class uses
encapsulation as a means of controlling the means of production and
lording it over the Class User class.  OOP being the realization of
two-bit bourgeois philosphy and all, I think it's clear what the real
purpose of Class based programming languages are.  Revolt! A bunch of
over-valued companies and their hordes of sloppy Hegelian programmers
are trying to take over your computer!  Resist the categorical
imperative, and do not let applied dialectics control your life!

-- 
Craig Brozefsky                      <craig@red-bean.com>
Free Scheme/Lisp Software  http://www.red-bean.com/~craig
"Hiding like thieves in the night from life, illusions of 
oasis making you look twice.   -- Mos Def and Talib Kweli