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=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fac41,8ff80a74f45b5cd3 X-Google-Attributes: gidfac41,public X-Google-Thread: 103376,8ff80a74f45b5cd3 X-Google-Attributes: gid103376,public From: Nick Leaton Subject: Re: Visibility and access to "public" attributes Date: 1997/09/05 Message-ID: <34101640.8CF27E0@calfp.co.uk>#1/1 X-Deja-AN: 269986647 X-NNTP-Posting-Host: calfp.demon.co.uk [158.152.70.168] References: <01bcb787$eeb5a180$7e80400a@gavinspc> Reply-To: nickle@pauillac Newsgroups: comp.lang.ada,comp.lang.eiffel Date: 1997-09-05T00:00:00+00:00 List-Id: Gavin Collings wrote: > > Don Harrison wrote in article > ... > > I wrote: > > > > :Mike Card wrote: > > > > :I accept this more accurately emulates the Eiffel functionality, and.. > > : > > ::.. there is no restriction in Ada that prevents an access function > > ::from having the same name as a class' (tagged type's) attribute. > > : > > :True. > > > > What remains, of course, is the fact that the Eiffel mechanism is simpler > > and more direct - objectively-speaking, that is. :) > > > > Why objectively? Because in Eiffel, the attribute is made available in one > > step and in Ada, two steps. Less steps implies directness which, in turn, > > implies simplicity, so we can conclude that the Eiffel mechanism is both > > more direct and simpler. > > ... than Ada ... Agreed. Would you care to contrast the Eiffel mechanism > (objectively, of course) with that specified for Delphi properties. Here I > have complete freedom to define within say class circle. > > property Radius : Double read fRadius - gives a read-only radius > or property Radius : Double read fRadius write fRadius - gives direct > read/write access > or property Radius : Double read fRadius write SetRadius - accessor called on > set > > and write client code like > > circle1.radius := circle2.radius; > > Apart, perhaps, from the overhead of having to declare fRadius separately, > this method looks certainly more flexible and probably in most interesting > cases more direct than the Eiffel approach. > I did a quick bit of analysis on some Eiffel software. 193 set_attribute features in 1085 classes, consisting of 84,000 lines of code. This is a very low figure compared to the number of attributes. I think the explaination lies with class invariants. In other languages where you write lots of set attribute features, you tend to use them to construct an instance of the class. You cannot do this so easily in Eiffel if you have a class invariant, as it must be preserved. As a consequence you tend to write a creation routine, which takes the necessary arguments, so that you can construct such objects without breaking the invariant. Since your object is now created, there tend to be fewer attributes that you want to set once it has been created. The other reason for the low figure is that these classes are part of class heirachies, and you have to take this into account. -- Nick Eiffel - Possibly the best language in the world - unless proven otherwise.