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,2c6139ce13be9980 X-Google-Attributes: gidfac41,public X-Google-Thread: f43e6,2c6139ce13be9980 X-Google-Attributes: gidf43e6,public X-Google-Thread: 1108a1,2c6139ce13be9980 X-Google-Attributes: gid1108a1,public X-Google-Thread: 103376,3d3f20d31be1c33a X-Google-Attributes: gid103376,public From: Owen Fellows Subject: Re: Interface/Implementation (was Re: Design by Contract) Date: 1997/09/15 Message-ID: <341D4AC2.8470493F@calfp.co.uk>#1/1 X-Deja-AN: 272665703 References: <5v34m5$pl9$2@trumpet.uni-mannheim.de> X-NNTP-Posting-Host: calfp.demon.co.uk [158.152.70.168] To: Marc Wachowitz Newsgroups: comp.object,comp.software-eng,comp.lang.ada,comp.lang.eiffel Date: 1997-09-15T00:00:00+00:00 List-Id: Marc Wachowitz wrote: > This is based on the Eiffel philosophy that every computation must be based > on a method invocation for some object, and that independent variables or > routines would be bad. Even the creation methods must be called in relation > to an already created instance. The work-around (in my view - Eiffel fans > might praise it as something logical) for library-functions is to have clients > inherit from some class (or use other quite absurd tricks, based on classes > without fields) to get at something like mathematical functions which do in > fact only depend on their arguments, not on any "receiver". Thus the use of a > routine library tends to be modeled as inheriting from a class providing them. > > (To Eiffel fans: Yes, I've read Bertrand Meyer's arguments for a "pure" object > oriented view, where classes are the only modules and where there aren't any > non-instance-related routines. Having pondered these things for some time now, > I don't agree at all, and prefer having non-class modules and some routines > which aren't related to any instances.) Originally I had this view too. But after some heavy use of Eiffel, and some thinking about the problem I have come to the conclusion that it isn't a problem. The solution would be to have an extra section that is implemented in the same was as 'inherit'. If we call it 'use', then if you wanted access to mathematical functions such as sin, cosine then you would 'use' mathematician. Internally there would be no difference in implementation. By default the 'use'd class would be exported to {NONE}. This prevents someone have a class A that 'use's MATHEMATICIAN using an instance of a to get access to sin, cosine etc. eg. a.sin (10) But it it more likely that you just inherit MATHEMATICIAN somewhere in your heirarchy to save on typing. You can prevent the above with just inheriting by exporting to {NONE}, but I have found in practice that this isn't a problem as if you don't have access to sin without using the form in the example, people just inherit MATHEMATICIAN. So, my argument would be what do you gain my adding something like 'uses'? Not much. What do you lose by not having it? Not a lot. Having the same implementation as inherits is a hint that it probably is inherits! Most people have a problem with this because of the inheirtance corresponds to is-a. In practice we have marked which classes are used for facility inheritance by choosing names for the classes that make sense, and by placing them at the end of the inheritance clause. nickle@calfp.co.uk Nick, via Owen Fellows account