From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fac41,c52c30d32b866eae X-Google-Attributes: gidfac41,public X-Google-Thread: 1108a1,c52c30d32b866eae X-Google-Attributes: gid1108a1,public X-Google-Thread: 103376,2ea02452876a15e1 X-Google-Attributes: gid103376,public From: jhd@herold.franken.de (Joachim Durchholz) Subject: Re: Real OO Date: 1996/05/07 Message-ID: <68P6zfWk3RB@herold.franken.de>#1/1 X-Deja-AN: 153542106 references: <67SpgKdV3RB@herold.franken.de> newsgroups: comp.lang.eiffel,comp.lang.ada,comp.object Date: 1996-05-07T00:00:00+00:00 List-Id: 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.