Re: Visibility and access to "public" attributes

[Nick Leaton <nickle@calfp.co.uk>]

Gavin Collings wrote:
> 
> Don Harrison <nospam@thanks.com.au> wrote in article
> <EFv4p4.ME2@syd.csa.com.au>...
> > 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.