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: jsa@organon.com (Jon S Anthony) Subject: Re: Real OO Date: 1996/05/06 Message-ID: #1/1 X-Deja-AN: 153397786 sender: news@organon.com (news) references: organization: Organon Motives, Inc. newsgroups: comp.lang.eiffel,comp.lang.ada,comp.object Date: 1996-05-06T00:00:00+00:00 List-Id: In article <67pyPs0-3RB@herold.franken.de> jhd@herold.franken.de (Joachim Durchholz) writes: > jsa@organon.com wrote 30.04.96 on Re: Real OO: > > > Well, whether it is a "real" problem or not, you have to introduce > > contrived/extraneous classes in an attempt to define the things. > > Well, I can't avoid this if I equate module and class. Right. > 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. > > > poor abstraction that got through because the programmer > > So what makes a function a "poor" abstraction??? > > Use the definition that suits your taste :) . The one I use doesn't make it "poor" by definition! :-) Which means it can be perfectly appropriate alone at times. > > In the right > > context (and the one under consideration is a good example), it > > can be the perfect abstraction. > > Of course. My point wasn't that functions as abstractions cannot > be, it's just that *usually* functions are not the right tool. Seems like a reasonable view - and I didn't/don't disagree with it. > I don't think it is bad that everything is implemented as a class > even though I fully recognize that > > it just is plain not true that all the > > world's a class. > Still, classes are as good as any other concept for making a > module, so why not use them? Ahhh yes. This really sort of gets at this part of the issue. If you are going down the path of language design which basically tries to provide all that is necessary for a particular view of what it is to create "information structures and their operations" (in some circles aka programming...) with minimum required constructs and _acceptable_ inconvenience/distortion, then the above is clearly a reasonable view. It is even a good and laudable view. It is, in many respects, the view taken by Meyer in designing Eiffel. It is also not the only good and laudable view on such matters. The real problem with this view is simply that "programming" isn't really like mathematics (which clearly offers up the above sort of view in spades.) Now I like mathematics and this view a good deal - indeed, some of the more "pure" and esoteric nooks are what I am "officially" expert at. But software is much more like engineering than mathematics. And that means accepting certain constraints and realities which often do not fit the nice elegant models that would be preferable in a more "perfect" world. 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...) > 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... /Jon -- Jon Anthony Organon Motives, Inc. 1 Williston Road, Suite 4 Belmont, MA 02178 617.484.3383 jsa@organon.com