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: amitp@Xenon.Stanford.EDU (Amit Patel) Subject: Re: Real OO Date: 1996/04/30 Message-ID: <4m5ugh$ben@nntp.Stanford.EDU>#1/1 X-Deja-AN: 152291889 references: organization: Computer Science Department, Stanford University. newsgroups: comp.lang.eiffel,comp.lang.ada,comp.object Date: 1996-04-30T00:00:00+00:00 List-Id: In article , Robert Dewar wrote: [lots of good stuff deleted] >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. The row organization seems to correspond to "tagged unions" as in ML, or less safe structures like unions in C or variant records in Pascal. There are a fixed number of data variants, and you want to be able to write lots of code on them. Another example is a compiler, which has a fixed set of intermediate representation data variants (add, mul, mov, etc.) and a varying number of operations (code optimization passes). Each optimization pass can be put into a separate module, and new optimization passes can be added without modifying the intermediate code definition. If one tried to implement this with objects, then each optimization pass would be a method on the object. To add a new optimization, you have to modify *every* data variant. >A maximally effective programming language will be friendly to either the >"row" view or the "column" view, or flexible mixtures of the two. Agreed. - Amit