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,953e1a6689d791f6 X-Google-Attributes: gidfac41,public X-Google-Thread: f79bb,953e1a6689d791f6 X-Google-Attributes: gidf79bb,public X-Google-Thread: 103376,953e1a6689d791f6 X-Google-Attributes: gid103376,public From: gomes@ICSI.Berkeley.EDU (Benedict A. Gomes) Subject: Re: Eiffel and Java Date: 1996/11/01 Message-ID: <55dnhj$5sg@agate.berkeley.edu>#1/1 X-Deja-AN: 193757936 references: <550sm2$sn1@buggy.news.easynet.net> <55crp0$qn9@dscomsa.desy.de> organization: International Computer Science Institute, Berkeley, CA, U.S.A. newsgroups: comp.lang.eiffel,comp.lang.ada,comp.lang.sather Date: 1996-11-01T00:00:00+00:00 List-Id: In article <55crp0$qn9@dscomsa.desy.de>, Matthias Ernst wrote: > >One should not forget that Sather's rules also have disadvantages. Because >of the freedom you have it's nearly impossible to check routines once in the >superclass and then inherit them unchecked. The Sather compiler must recheck >every inherited routine in the context of its new class. > Though Sather does not do this, it would be easy at the language level to define a form of code inclusion that avoids this problem - there have been proposals to this effect- by providing the sort of encapsulated code inclusion that you get in Java. Since code inclusion is essentially a syntactic operation, new forms of code inclusion do not really impact other aspects of the language - they can be viewed as different kinds of macro operators. IMHO, this encapsulated form of code inclusion should actually be the default, though the current, looser version should still be possible. ben