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: 103376,2ea02452876a15e1 X-Google-Attributes: gid103376,public X-Google-Thread: 1108a1,c52c30d32b866eae X-Google-Attributes: gid1108a1,public From: dewar@cs.nyu.edu (Robert Dewar) Subject: Re: Real OO Date: 1996/04/30 Message-ID: #1/1 X-Deja-AN: 152230206 references: organization: Courant Institute of Mathematical Sciences newsgroups: comp.lang.eiffel,comp.lang.ada,comp.object Date: 1996-04-30T00:00:00+00:00 List-Id: Don Harrison said > :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. > In OO software, you would want to define them with their types > (except that in Eiffel, you assign the operation to a particular > type - whichever is most appropriate). Otherwise, you would end up > with spaghetti, IMO. It's always surprising how people get carried away with one narrow view of programming paradigms. It very much reminds me of the old saying that "if the only tool you have is a hammer, then all problems start to resemble nails". The idea that you should package operations with types is a very useful (and very old one). The particular enbodiment that we refer to as object oriented programming is in particular a very useful (and also very old) idea. But going one step further and saying that this idea is so effective that ALL software must be organized this way, and that any other organization is defective is simply not justified. As I say, this seems a common affliction in the programming languages field: o Functional programming is very useful, but disallowing notions of implicit state completely seems to be going much too far. o Proof of correctness is very useful, but insisting that programming languages be designed so that only programs with integral proofs can be written seems to be going much too far. o Strong typing is very useful, but insisting that separate types be used for every separate notion, no matter on how small a scale, is going too far. o Top-down structured design is very useful, but insisting that ALL programs use only this design approach is going too far. etc. To me the "pure" OO view that Don expresses is yet another example of this excess of zeal. There are many instances in which it makes sense to package operations by classifying operations, rather than types. For example, It seems quite appropriate to have a set of procedures for matrix diagonalization packaged up together, rather than bundled in with the matrix type (indeed the idea of bundling all possible matrix operatoins up with the matrix type is untenable). Similarly, it makes sense to have trig functions for various floating-point types bundled up in a package, rather than scattered around. The world of operations and types can be though of as a matrix: type 1 type 2 type 3 ... op1 x - x op2 - x - op3 x x - ... Roughtly speaking, the OO approach organizes by columns, which is often fine, but the operation organization by rows also often makes sense. For example, if op3 represents some complex numerical procedures, understood only by a small group of experts, it may well be better to bundle up op3 rather than distributing the op3 code around the separate types. A maximally effective programming language will be friendly to either the "row" view or the "column" view, or flexible mixtures of the two. P.S. spaghetti code doesn't just mean code you don't like. It is a rather specific term used to described the non-nested chaotic control structures caused by undisciplined use of gotos or equivalent transfers of control. I think it is useful to keep this sense.