Re: Real OO

[jsa@organon.com (Jon S Anthony)]

In article <67SpgKdV3RB@herold.franken.de> jhd@herold.franken.de (Joachim Durchholz) writes:

> > Simply this:  Classwide operations can be defined anywhere by anyone.
> > They do not have to be defined along with the primitive types in
> > their packages.
> 
> Umm, that's not a real problem. Whenever I need an additional  
> routine that the original class designer forgot, I create a mixin  
> class that I inherit wherever I want to use it. I don't even have  
> to insert it anywhere in the inheritance structure, as I can  
> multiply-inherit it where I want it. Or I can write a class  
> function_library[T -> INTEGER] and have an INTEGER library.

Well, whether it is a "real" problem or not, you have to introduce
contrived/extraneous classes in an attempt to define the things.


> Though I admit it requires me to write two or three additional  
> lines of code (class header and final END), and I feel it is  
> using a big concept (classes) for a small task (writing a simple  
> routine). But I like to think that forcing me to write a class I  
> also begin thinking about making a real class instead of just a  
> function - and I have the impression that many functions are just  
> that, poor abstraction that got through because the programmer  

So what makes a function a "poor" abstraction???  In the right
context (and the one under consideration is a good example), it
can be the perfect abstraction.  The real problem is, _all you
have are classes_, and it just is plain not true that all the
world's a class.


> wanted a quick-and-dirty solution. (Of course, if it is just a  
> function even after analysis, I'm still stuck with a class  
> instead of a function.)

Indeed.  And in the scenario I presented this is exactly the situation.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com