Re: Real OO

[jhd@herold.franken.de (Joachim Durchholz)]

jsa@organon.com wrote 06.05.96 on Re: Real OO:

> > In Ada, I'd have to create lots of extraneous packages - doesn't
> > sound much of a difference to me. You always need some syntactic
> > sugar
>
> No, in Ada I can just write a function.  Or procedure.  I can also
> write a package if I think it makes sense.  So, no, there is no
> similar requirement.  Since classwide operations are not primitive,
> they do not need to part of a package.

Caught me - it's actually a few years since I looked at anything that  
related to Ada. Humm... let's see... the book says it's from 1981, and  
I bought it shortly after it was available. It's *really* been a long  
time. And now that I look at it, that ancient standard actually allows  
single routines to be compiled - I stand corrected.

> > Still, classes are as good as any other concept for making a
> > module, so why not use them?
>
> So, why not use classes for modules?  Basically because that is not
> really their major semantic intent (not just in "programming" but in
> any taxonomic modeling scenario).  Sure, you can say, "so what?", and
> pull a Humpty Dumpty and further say, "in this nook of the world, they
> do have this intent."  Fine.  But saying it's so doesn't make it so.
> And I haven't seen a convincing argument for this position (maybe
> there is one, and I just haven't seen it...)

Well, it's the same with functions and routines. They were introduced  
to reuse code (rings a bell, doesn't it?). But nowadays I find myself  
using them just for naming a chunk of code.
This is a blatant abuse of the concept of a subroutine; after all, I  
don't call the routine more than once! But in this nook of the world,  
a routine is the only way to name a piece of code. (Usually. I once  
programmed in a language that had such a feature. It was called ELAN,  
designed specifically for education, and I've never seen a commercial  
compiler for it.)

> > Usually, an abstraction isn't embodied in a single class, but in
> > a set of related classes. While the notion of "class" is
> > heavyweigth, actual classes are often quite lightweight.
>
> Sounds like a subsystem.  And it would be nice to have some construct
> with which you could express this collection of classes within the
> model that contains the particular notion of class with which you're
> working.  A construct whose job it was to collect and organize sets of
> arbitrary sorts of things...

Well, in Eiffel, these are called clusters. They aren't really part of  
the language standard, but ISE's compiler organizes the classes into  
clusters, and the other vendors follow suit here. It's somewhat alike  
the convention of naming include files *.h in C - never formalized,  
but everybody adheres.

-Joachim

--
Looking for a new job. Resume available on request.