Re: Visibility and access to "public" attributes

["Gavin Collings" <gcollings@sperry-sun.com>]

Nick Leaton <nickle@calfp.co.uk> wrote in article
<340BF0B7.BF7D3029@calfp.co.uk>...
> Gavin Collings wrote:
> > 
> > Don Harrison <nospam@thanks.com.au> wrote in article
> > > What remains, of course, is the fact that the Eiffel mechanism is
simpler
> > > and more direct - objectively-speaking, that is.  :)
> > 
> > ... 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.
> > 
> > [snip radius property example]
> > 
> > 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.

I'm not entirely sure what you mean, but if your asking can you define an
Area property that defines side effects which act purely on the radius, the
answer is yes.  It works like this:

   property Area : Double read GetArea write SetArea

Then you can define the accessors - e.g. SetArea:

   procedure SetArea( newArea : Double )
   begin
      fRadius := sqrt( newArea / pi );
   end

Now I can write client code like:

   circle1.Area := 50.0;

You have complete control over which properties are read-only/read-write and
which directly access their respective fields (e.g. fRadius) or go via an
accessor method.

If you meant something else, you'd better elaborate a little.

-- 
Gavin Collings
gcollings@sperry-sun.com