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: 109fba,97482af7429a6a62 X-Google-Attributes: gid109fba,public X-Google-Thread: 10d15b,97482af7429a6a62 X-Google-Attributes: gid10d15b,public X-Google-Thread: 1108a1,371d317eff97da58 X-Google-Attributes: gid1108a1,public X-Google-Thread: 10a640,9ca80649c409e17e X-Google-Attributes: gid10a640,public X-Google-Thread: 103376,97482af7429a6a62 X-Google-Attributes: gid103376,public From: Erik Naggum Subject: Re: C++ not OOP? (Was: Language Efficiency Date: 1995/04/21 Message-ID: <19950421T230840Z.enag@naggum.no>#1/1 X-Deja-AN: 101368877 references: <3mbmd5$s06@icebox.mfltd.co.uk> <3n8jdv$jer@watnews1.watson.ibm.com> <3n8rjd$90a@disunms.epfl.ch> organization: Naggum Software; +47 2295 0313 newsgroups: comp.object,comp.lang.c++,comp.lang.ada,comp.lang.cobol,comp.lang.clos Date: 1995-04-21T00:00:00+00:00 List-Id: [Fernando Mato Mira] | In article <3n8jdv$jer@watnews1.watson.ibm.com>, ncohen@watson.ibm.com (Norman H. Cohen) writes: | | > It should be noted that even in languages without direct linguistic | > support for multiple dispatch, the same effect can be achieved in a | > straightforward way by redispatching. | | Of course. And you can achieve the same effect as single-dispatch by | using function pointers in a C program.. unless I have missed something crucial, I think both of you may have missed something crucial. your idea seems to be to have Grand Unifying Classes from which devices and shapes inherit Grand Unifying Methods, such that all shapes are implemented using a set of abstract methods that all devices implement. I object to the very idea of Grand Unifying Classes, on the grounds that abstraction that achieves a Unifying Abstraction over devices (in particular) will have great cost in both the abstraction process and the implementation, more notably the abstraction process. whereas it is nearly trivial to design and implement drawing a shape on a device using device-specific code, it is exceedingly hard to design the Abstract Device that will capture sufficient power of real devices, not to mention ways to optimize the Grand Unifying Methods for a particular device. one of the reasons that I found "object-oriented" programming in C++ to be exceedingly hard was the requirement to make counter-intuitive and overly abstract abstractions only to conform to the lack of ability to dispatch to the proper classes. I have only experimented with CLOS and Dylan, but what I found was indeed that I could write better code to do specific tasks, and that I could intuit the abstract classes, if and when appropriate _after_ I had the necessary experience to talk about them, and _after_ I had a chance to decide whether they were indeed appropriate. for me, programming is a learning process, and I found that C++ was actively hindering that process, whereas both CLOS and Dylan encourage me to make abstractions when I have a greater understanding, an understanding that could not exist prior to design and implementation of individual subclasses of some Unknown Grand Unifying Class. maybe I'm doing something wrong, but premature abstraction seems as bad as or worse than premature optimization, both of which are encouraged by C++ and discouraged by both CLOS and Dylan. (I'd appreciate if someone more experienced in either language would let me know if I'm wandering off in the wrong direction.) # -- sufficiently advanced political correctness is indistinguishable from irony