Re: Visibility and access to "public" attributes

[card@syr.lmco.com]

In my original post on this subject, I wrote:

>That said, I think it is fair to say that I believe the idea behind
>Ada's "all or nothing" approach is that you may want to ensure that
>a client never depends on some of a type's attributes. For instance,
>you might have an Aircraft class with a Take_Off method. Should a
>client be able to view (and thus potentially depend upon) attributes
>in the Aircraft type that might change but would not impact the
>interface to Take_Off?

To which Patrick Doyle replied:

>If the attributes change, then what used to be an attribute
>can be changed into a function with absolutely no effect on
>client code.  (And, if it turns out to be impossible to do
>this, then you have a problem on your hands even in Ada.)
>The Eiffel approach is *no different* from using accessors.

The issue I'm raising here is the ability of a client to
depend on a class' attribute (feature). To expand on the
Aircraft example a bit (pardon my Eiffel- I don't write the
langauge fluenty; I'm just a tourist! ;) )

class AIRCRAFT
   Take_Off; -- I don't know how you write methods in Eiffel!
feature

  Propeller_RPM: Integer;

end

Now, suppose you change the AIRCRAFT class to have jet engines and
thus remove or change the Propeller_RPM attribute? Because it was
*visible*, someone may have written code to read it and now if you
change the spec of the class their code will break. It doesn't
matter that they can't update the attribute! If they can refer to it
at all and you remove the attribute from the class definition, their
code is broken! In this case, the only way to avoid breaking client
code written for the original definition of AIRCRAFT would be to
add a useless Propeller_RPM accessor that returns zero or something.

In this case, the AIRCRAFT class' features/attributes would have been
better off hidden, since the Take_Off method's interface didn't
change when the Propeller_RPM attribute was changed/removed.

Now, I would have the same problem in Ada if my Aircraft type were
declared with public attributes:

package X is
   type Aircraft is tagged
      record
         Propeller_RPM : Integer;
      end record;
   procedure Take_Off (AC : Aircraft);
end X;

A client of this package could write code that accesses (for read
or write, who cares) Propeller_RPM. If I change the definition
of Aircraft so that this attribute no longer exists, the client
code breaks just like in the Eiffel case.

That's the issue I'm writing about: impact on client code. When
in Eiffel would you want to allow a client to be dependent on a
type's implementation in this way?

Now to Pat's question:

>What I'd like to know is, how do you decide in Ada whether
>to make an attribute public, and thus irrevocably commit to
>allowing clients to assign to it?

Personally, I only do this for types which cannot be put in an
invalid state by the client setting the attributes, e.g.

package Example is

   type Point is abstract tagged null record;
   function Distance (P1, P2 : Point) return Integer;

   type 1D_Point is new Point with
      record
         X: Integer;
      end record;
   function Distance(P1,P2 : 1D_Point) return Integer;

   type 2D_Point is new 1D_Point with
      record
         Y : Integer;
      end record;
   function Distance (P1, P2 : 2D_Point) return Integer;

end Example;

Here, the 1D_Point and 2D_Point classes cannot be put into
inconsistent/invalid states as a result of the client setting
the X and Y coordinates. The distance between them can always
be computed (within arithmetic range of machine, of course).

Now, if I had a type with more complex methods
and it was possible for a user-adjusted attribute to put the
object into an inconsistent state, then I would make its
attributes private and the attributes would be set only by
higher-level methods. That is, I wouldn't provide a low-level
accessor to set an attribute if doing so could allow the object
to be put into an invalid state.

- Mike

---------------
Michael P. Card
Lockheed Martin Ocean, Radar and Sensor Systems Division
Syracuse, NY 13221
voice: (315)-456-3022  FAX: (315)-456-2414  e-mail:card@syr.lmco.com

-------------------==== Posted via Deja News ====-----------------------
      http://www.dejanews.com/     Search, Read, Post to Usenet