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/05/07 Message-ID: <4mog94$hnv@nntp.Stanford.EDU>#1/1 X-Deja-AN: 153572920 references: <4m5ugh$ben@nntp.Stanford.EDU> <4m80qu$jn3@watnews1.watson.ibm.com> organization: Computer Science Department, Stanford University. newsgroups: comp.lang.eiffel,comp.lang.ada,comp.object Date: 1996-05-07T00:00:00+00:00 List-Id: Norman H. Cohen wrote: >In article <4m5ugh$ben@nntp.Stanford.EDU>, amitp@Xenon.Stanford.EDU >(Amit Patel) writes: > >|> 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. > >An optmization is an operation on a sequence of instructions, not on an >instruction. It makes no sense to apply an Optimize operation to an ADD >instruction. Okay, I agree. The problem still exists, in a slightly different setting. There may be several operations on `instructions', like code generation for different platforms (assuming architectures are similar enough), or display for debugging purposes. The diagram is: Gen1 Gen2 Disp ---- ---- ---- ADD X X X SUB X X X ---------> CODE MOV X X X JMP X X X | | V DATA If you only want to add new operations, then you can use tagged unions, and you can extend in the CODE axis. If you only want to add new instructions, you can use objects, and you can extend in the DATA axis. If you pick the `wrong' solution for the problem (i.e., tagged unions when you want to add new instructions), then you get an inflexible system. Lots of OO textbooks show examples where you have to modify *every* module (each containing one operation) in your system in order to add a new data variant. What the OO books don't tell you is that the same thing is true for the other `wrong' solution: objects when you want to add new operations. If operations are methods, and each module contains one data variant, then to add a new method you must modify *every* module in your system. Unfortunately, this case is usually overlooked. The textbooks are concerned only with extending things in the DATA axis, and not the CODE axis. IMO, they should stress *analyzing* the problem to determine whether future extensibility will be primarily in the DATA or CODE axis. If it in the DATA axis, objects should be used for that data type. If it in the CODE axis, then objects should *not* be used, but rather, tagged unions should be used. I think this entire OOD revolution has gone too far in taking SOME examples where you want data flexibility and generalizing by saying that ALL cases require data flexibility. ("Everything is an object! So-and-so language is PURE!") There are cases where code flexibility is more important than data flexibility, and those cases are where the traditional solutions of having a 'tag' and a case statement make more sense. Let's not throw out everything that we did before! - Amit -- Amit J Patel, Computer Science Department, Stanford University http://www-cs-students.stanford.edu/~amitp/ "I am always ready to learn, but I do not always like to be taught." - Winston Churchill