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.
> 

A bit obscure. Lets say you also have area as a readable atribute.
Setting the area is possible, since we can derive the radius as a
consequence. How does
that work with Delphi.

-- 

Nick

Eiffel - Possibly the best language in the world - unless proven
otherwise.