Re: Visibility and access to "public" attributes

[Ted Velkoff <velkoff@erols.com>]

card@syr.lmco.com wrote:
> [ ... earilier discussion deleted ...]
> 
> 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?
> 

If you'll forgive my syntax errors in Ada95, I'll put what I believe to 
be equivalent Ada and Eiffel side by side.

				Example 1
package AIRCRAFT is				class AIRCRAFT feature
  type CLASS is tagged private;
  procedure take_off (c : CLASS'class);		  take_off is do .. end
  function propeller_rpm return INTEGER;	  propeller_rpm :INTEGER
private
  type CLASS is record
    propeller_rpm : INTEGER
  end record;
end package;					end

				versus

				Example 2
package AIRCRAFT is				class AIRCRAFT feature
  type CLASS is tagged private;
  procedure take_off (c : CLASS'class);		  take_off is do .. end
  -- function propeller_rpm not exported
private						feature {NONE}
  type CLASS is record
    propeller_rpm : INTEGER			  propeller_rpm :INTEGER
  end record;
end package;					end

Eiffel has a fine-grained export mechanism.  In the second example it is 
used to hide the attribute.

If I understood your question I believe you were concerned that the 
Eiffel in the first example was equivalent to the Ada95 of the second, 
and it is not.

In the first example, in either language, client code breaks, but I 
think that is inevitable.  That's because we made a modelling error: we 
assumed all AIRCRAFT had propellers, an assumption that turned out to be 
wrong.  It might be worth pointing out also that this modelling problem 
appears in the Ada even when the attributes are private (as in example 
1).  As you say, the key decision is whether or not to provide access to 
clients, be it via function or attribute.

Incidentally, when an interface change like this causes client code to 
break, there is a little language feature in Eiffel called "obsolete", 
which can be used to generate compile-time messages indicating the 
(client) dependence on a feature scheduled (at some future time) to be 
removed.  That is intended to help with the problem of simply 
communicating the change to all affected developers.  (How many times 
have we all been hauled into a lab to fix code of ours that didn't 
compile due to changes by someone else that we never knew about! :-) )

-- Ted Velkoff