Re: Visibility and access to "public" attributes

Re: Visibility and access to "public" attributes

[card]

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

Re: Visibility and access to "public" attributes

[Ted Velkoff]

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

Visibility and access to "public" attributes

[card]

Earlier today, I saw an interesting discussion about the way Ada and
Eiffel perform "information hiding". In Ada, a type is is either
public (i.e. its attributes can be read and written by a client of
the type) or private (the attributes of the type are not visible
and can only be accessed using the type's public methods).

In Eiffel, by contrast, a type can be "semi-private", by which I mean
that its attributes can be made visible for read purposes but not
write purposes. This was said to be superior to the Ada method of
using a private type with access functions to get at its attributes
because in Ada the access functions couldn't have the same name as
the attributes, i.e. you'd need a function named "Get_X" to read the
value of attribute X, while in Eiffel you could just use "X". I
excerpt the following from Don Harrison's post:

>To get similar read-only semantics in Ada, you have to declare the
>attribute in the package body (hiding it) and return it via an
exported
>function (which can't have the same name):
>
>  the_a: SOME_TYPE
>  ...
>  function a return SOME_TYPE is
>  begin
>    return the_a;
>  end;

First of all, let me say that in Ada the closest analogue to an
Eiffel/C++ style class (one in which the unit of modularity is
the same as the type) is a tagged type and its dispatching
operations. In Ada, it is certainly possible to have access
functions which have the same names as the attributes of their
tagged type. The following is some compilable Ada code that
illustrates this:

package Test1 is
   type My_Type is tagged private;           -- attributes invisible
   function A(Obj : My_Type) return Boolean; -- access function
private
   type My_Type is tagged
      record
         A : Boolean;                        -- attribute
      end record;
end Test1;


package body Test1 is
   function A(Obj : My_Type) return Boolean
   is
   begin
      return Obj.A;
   end A;
end Test1;

Thus, there is no restriction in Ada that prevents an access function
from having the same name as a class' (tagged type's) attribute.

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?

I know that Eiffel can totally hide the attributes of an object (i.e.
accessed via methods only) as well. When writing Eiffel programs, how
do you decide when to make a type's attributes "read-only visible"
and when to hide them?

- 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

Re: Visibility and access to "public" attributes

[Patrick Doyle]

In article <872873007.3110@dejanews.com>,  <card@syr.lmco.com> wrote:
>
>package Test1 is
>   type My_Type is tagged private;           -- attributes invisible
>   function A(Obj : My_Type) return Boolean; -- access function
>private
>   type My_Type is tagged
>      record
>         A : Boolean;                        -- attribute
>      end record;
>end Test1;
>
>
>package body Test1 is
>   function A(Obj : My_Type) return Boolean
>   is
>   begin
>      return Obj.A;
>   end A;
>end Test1;
>
>Thus, there is no restriction in Ada that prevents an access function
>from having the same name as a class' (tagged type's) attribute.

  Ok, but remember that this same piece of code would look like
this in Eiffel:

class TEST1

feature

  A : BOOLEAN

end

  Of course, every language has things it's good at and things
it's not so good at, but this to me seems a fairly common pattern
in OOP.

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

  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.

>I know that Eiffel can totally hide the attributes of an object (i.e.
>accessed via methods only) as well. When writing Eiffel programs, how
>do you decide when to make a type's attributes "read-only visible"
>and when to hide them?

  The same way you decide in Ada whether or not to provide an
accessor function.

  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?

 -PD

-- 
--
Patrick Doyle
doylep@ecf.utoronto.ca

Re: Visibility and access to "public" attributes

[Darren New]

In article <872885107.17682@dejanews.com>,  <card@syr.lmco.com> wrote:

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

Suppose you decide you have a kind of airplane that can't Take_Off?

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

Don't make it public if you're not going to support it. Exactly the same
argument could be make for the Take_Off procedure.

What if you had another function called "Is_Flying". What if that was
stored as a boolean variable?  What if it was actually a boolen function?
Why should the client need to know the difference between the two?

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

Again, you can say the same for "Take_Off."

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

If you wrote a program that relied on knowing the Propeller_RPM (say,
a flight simulator sound module, or a cockpit display instrument),
then yes, it'll break when you no longer have propellers. Is that
suprising?

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

Ah, there's the rub.  The "Propeller_RPM" isn't part of the
implementation. It's part of the specification. You're saying that the
clients can query the Propeller_RPM and see an INTEGER. If that's 100%
implementation, then hide it. If it's something clients need to do,
then you can't hide it *or* remove it.

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

Yup.  In Eiffel, you would have a "set_rpm" procedure to set the value,
and the preconditions would tell you what the valid values are, and 
the postconditions would say that the new value of "rpm" is the same
as the argument to "set_rpm". This jibes, because in Eiffel you should
have functions that return values but don't make changes, and procedures
which make changed but don't return values.

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

And that's the same in Eiffel.  Or you can use preconditions on
your set functions if the conditions for validity are simple enough,
like "0 <= rpm and rpm <= 10000" or something.  For truely complex
conditions (like "the directed graph cannot have cycles") then you 
need functions to set the value, yes.

So where's the problem?  :-)

  --- Darren

Re: Visibility and access to "public" attributes

[Patrick Doyle]

In article <872885107.17682@dejanews.com>,  <card@syr.lmco.com> wrote:
>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

  Just to clarify, I think you mean this...

class AIRCRAFT

feature {ANY}

  take_off is do ... end

  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.

  There are two possiblities here:

1. You shouldn't have made Propeller_RPM visible in the first place.
The class should have looked like this:

class AIRCRAFT

feature {ANY}

  take_off is do ... end

feature {NONE}

  propeller_RPM : INTEGER

end

2. If you made propeller_RPM visible, and now it no longer applies,
then sorry, but your design has changed and you're going to need to
rewrite some classes.  No language I know of will help here.

  I think the issue here is that you don't *have to* make attributes
visible. 

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

  Indeed.

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

  That's interesting, but the trouble is that a class can't possibly
know what's an invalid state for every conceivable object of that
class.  What I'm trying to say is that subclasses might have
constraints on the values of these attributes, and the superclass
can't be expected to know that in advance.  So if you expect
people to subclass (or even if you don't expect them to!),
then you should never allow clients to directly assign
values to attributes.

  Eiffel's syntax prevents people from making attributes writeable,
which IMHO is not a great loss.  It just keeps us from being lazy
and adding the appropriate encapsulating code.

 -PD

-- 
--
Patrick Doyle
doylep@ecf.utoronto.ca

Re: Visibility and access to "public" attributes

[Darren New]

In article <872873007.3110@dejanews.com>,  <card@syr.lmco.com> wrote:

>In Eiffel, by contrast, a type can be "semi-private", by which I mean
>that its attributes can be made visible for read purposes but not
>write purposes. 

I think you're thinking about this wrong. Think of an Eiffel "attribute"
as a function.  There happens to be special syntax you can use to determine
what that function returns, and you can only use that syntax inside the
body of the class declaring the attribute.

Given this, you're not exposing any internal details, any more than 
writing an Ada access function exposes internal details.

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

Then put the attribute you don't want seen in a "feature {NONE}" clause.
This is like complaining that you're writing access functions for
private variables you don't want clients seeing.

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

No. So hide them. :-)

>I know that Eiffel can totally hide the attributes of an object (i.e.
>accessed via methods only) as well. When writing Eiffel programs, how
>do you decide when to make a type's attributes "read-only visible"
>and when to hide them?

When you're willing for a client to depend on the value of the
attribute, then you make it visible. This is no different at all
from making visible access functions.

-- Darren

Re: Visibility and access to "public" attributes

[Patrick Doyle]

In article <JSA.97Aug29190453@alexandria.organon.com>,
Jon S Anthony <jsa@alexandria.organon.com> wrote:
>In article <EFotFL.I5t@ecf.toronto.edu> doylep@ecf.toronto.edu (Patrick Doyle) writes:
>
>> class TEST1
>> 
>> feature
>> 
>>   A : BOOLEAN
>> 
>> end
>> 
>>   Of course, every language has things it's good at and things
>> it's not so good at, but this to me seems a fairly common pattern
>> in OOP.
>
>I don't see how this is "better" overall.  It has its own
>disadvantages.  In the Ada case you can completely change the
>representation including the name of the attribute while keeping the
>accessors the same and not disturbing client code.  In the Eiffel case
>you can "hedge your bets" by not committing to this sort of thing up
>front (and thus possibly shooting yourself in the foot later).  It's
>just not that big of a deal as neither has any clear _objective_
>superiority over the other.

Watch this:

class TEST1

feature {ANY}

  A : BOOLEAN is do  Result := (B = 0)  end

feature {NONE}

  B : INTEGER

end

  I've changed the name and type of the attribute, and the public
interface has remained the same.

  If this isn't what you were talking about, could you explain?

>>   If the attributes change, then what used to be an attribute
>> can be changed into a function with absolutely no effect on
>> client code.
>
>Not if the name changes as well.

  See above.

>>   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?
>
>How is this an Ada or Eiffel or any language issue?  That's basically
>a design issue.  IMO, you should _always_ make the things private
>except for quick hacks.

  I guess it's just a language issue because Eiffel doesn't allow
data members to be assigned-to by clients.  Thus, if you're using
Eiffel, you never have to make this decision.  There are drawbacks--
you can't do the "quick hacks" you were talking about.

 -PD

-- 
--
Patrick Doyle
doylep@ecf.utoronto.ca

Re: Visibility and access to "public" attributes

[Jon S Anthony]

In article <EFqEr6.526@ecf.toronto.edu> doylep@ecf.toronto.edu (Patrick Doyle) writes:

>   I've changed the name and type of the attribute, and the public
> interface has remained the same.
> 
>   If this isn't what you were talking about, could you explain?

No it is not - you didn't change the name.  A is still called "A", but
I don't believe that such a situation (literally changing the name) is
something that is likely to be even a small deal in practice.


/Jon
-- 
Jon Anthony
OMI, Belmont, MA 02178, 617.484.3383 
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: Visibility and access to "public" attributes

[Patrick Doyle]

In article <JSA.97Aug30151651@alexandria.organon.com>,
Jon S Anthony <jsa@alexandria.organon.com> wrote:
>In article <EFqEr6.526@ecf.toronto.edu> doylep@ecf.toronto.edu (Patrick Doyle) writes:
>
>>   I've changed the name and type of the attribute, and the public
>> interface has remained the same.
>> 
>>   If this isn't what you were talking about, could you explain?
>
>No it is not - you didn't change the name.  A is still called "A", but
>I don't believe that such a situation (literally changing the name) is
>something that is likely to be even a small deal in practice.

  Ok, I misunderstood.  Can you show me what you meant in Ada code?

 -PD

-- 
--
Patrick Doyle
doylep@ecf.utoronto.ca

Re: Visibility and access to "public" attributes

[card]

I'd like to thank everyone who replied to my original
post RE: visibility of attributes.

I had wondered when/why one would make a class'
attributes read-only rather than hiding them altogether.
The answer to my question was provided by Peter Horan:

>One must export parameters and functions when they
>are needed to verify pre-conditions. This is an
>Eiffel validity requirement (VAPE). (I am reminded
>of keeping one's fingers crossed when making
>promises :-)). This does not apply to features in
>post-conditions and invariants, which may be more
>restrictive than the client needs without harm.

This makes sense. Since everything in a precondition
must be visible to a class's client(s), then the
client must be able to read the class's attributes
(features) if they are used in the precondition(s).

Thanks, Pete!

- 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

Re: Visibility and access to "public" attributes

[Jon S Anthony]

In article <EFv4p4.ME2@syd.csa.com.au> nospam@thanks.com.au (Don Harrison) writes:

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

One step versus two steps sounds objective.  The rest here is not.

>  It seems that the meaning of the word "subjective" is, shall we
> say, subjective.

Probably.

/Jon
-- 
Jon Anthony
OMI, Belmont, MA 02178, 617.484.3383 
"Nightmares - Ha!  The way my life's been going lately,
 Who'd notice?"  -- Londo Mollari

Re: Visibility and access to "public" attributes

[Gavin Collings]

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.

-- 
Gavin Collings
gcollings@sperry-sun.com

Re: Visibility and access to "public" attributes

[Nick Leaton]

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.

Re: Visibility and access to "public" attributes

[Patrick Doyle]

In article <01bcb787$eeb5a180$7e80400a@gavinspc>,
Gavin Collings <gcollings@sperry-sun.com> wrote:
>
> [Discussion of how Delphi can make functions use the syntax of
>  an assignment statement]
>
>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.

  IMO, this is equivalent to being able to do this:

class GOOBER

feature

  volume : INTEGER is do ... end

  volume := (new_value : INTEGER) is do ... end

end

  Now I could write something like this:

my_goober.volume := my_goober.volume + 1

  While apparently an assignment, this would call "volume", add 1 to
the result, and then call "volume :=" passing it the new value as
an argument.

  While this may be nice syntactic sugar, naming a feature "volume :="
seems to have virtually no advantage over "set_volume".  

 -PD
  

-- 
--
Patrick Doyle
doylep@ecf.utoronto.ca

Re: Visibility and access to "public" attributes

[Don Harrison]

Mike Card wrote:

[..]

Example of how to emulate Eiffel's look-but-dont-touch attributes:

:package Test1 is
:   type My_Type is tagged private;           -- attributes invisible
:   function A(Obj : My_Type) return Boolean; -- access function
:private
:   type My_Type is tagged
:      record
:         A : Boolean;                        -- attribute
:      end record;
:end Test1;
:
:
:package body Test1 is
:   function A(Obj : My_Type) return Boolean
:   is
:   begin
:      return Obj.A;
:   end A;
:end Test1;

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.

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

As you acknowledge below, this can be done in Eiffel by hiding all the 
attributes of the type.. (See slso my response to Jon). 

:I know that Eiffel can totally hide the attributes of an object (i.e.
:accessed via methods only) as well. When writing Eiffel programs, how
:do you decide when to make a type's attributes "read-only visible"
:and when to hide them?

You export them when they're needed (or may be needed) by clients; otherwise,
you hide them.


Mike subsequently wrote:

: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!

As others have pointed out, the problem here is that your design for the 
AIRCRAFT class, rather than the Eiffel mechanism, is deficient - it 
assumed the aircraft was propeller-driven.


Don.                     (Reverse to reply)
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             au.com.csa.syd@donh

Re: Visibility and access to "public" attributes

[Peter Horan]

Don Harrison wrote:
> 
> Mike Card wrote:
> 
> [..]
> :I know that Eiffel can totally hide the attributes of an object (i.e.
> :accessed via methods only) as well. When writing Eiffel programs, how
> :do you decide when to make a type's attributes "read-only visible"
> :and when to hide them?
> 
> You export them when they're needed (or may be needed) by clients; otherwise,
> you hide them.
> 
One must export parameters and functions when they are needed to verify
pre-conditions. This is an Eiffel validity requirement (VAPE). (I am
reminded of keeping one's fingers crossed when making promises :-)).
This does not apply to features in post-conditions and invariants, which
may be more restrictive than the client needs without harm.

-- 
Peter Horan                     School of Computing and Mathematics
peter@deakin.edu.au             Deakin University
+61-3-5227 1234 (Voice)         Geelong, Victoria 3217, AUSTRALIA
+61-3-5227 2028 (FAX)           http://www.cm.deakin.edu.au/~peter

Re: Visibility and access to "public" attributes

[Don Harrison]

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.

It seems that the meaning of the word "subjective" is, shall we say, subjective.
To many, it has the usual meaning of "depending on individual perception".
To some, it means:

  "A quality which I can ascribe to a statement made by an opponent 
   which I know to be valid but believe my opponent will find difficult, 
   if not impossible, to justify by irrefutable argument."


Don.                     (Reverse to reply)
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             au.com.csa.syd@donh

Re: Visibility and access to "public" attributes

[Gavin Collings]

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

Re: Visibility and access to "public" attributes

[Don Harrison]

Gavin Collings wrote:

:...Would you care to contrast the Eiffel mechanism
:(objectively, of course) with that specified for Delphi properties. 

I probably shouldn't since I'm not familiar with Delphi. However, I'm tempted
to offer a few comments:

1) The second option (direct read-write access) presumably breaks encapsulation
   so is unsafe.

2) The second and third options are obscure, as Nick said. It appears possible 
   for assignment to have different meanings in the same context. 

   If so, I think it would be confusing compared with Eiffel's

   c.set_radius (value)      -- for clients, and
   radius := value           -- for suppliers.

3) It's more complex than Eiffel's minimalist approach.


Roger Browne would probably have some valuable insight on this..


Don.                     (Reverse to reply)
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             au.com.csa.syd@donh

Re: Visibility and access to "public" attributes

[Patrick Doyle]

In article <34101640.8CF27E0@calfp.co.uk>,
Nick Leaton  <nickle@pauillac> wrote:
>
>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.

  And if this were merely syntactic sugar, then it would seem unnecessary.
However, the ability to change the semantics if the ":=" operator in
existing code is a powerful one, comparable to the ability to change
what was an attribute access into a function call.

  If this were available, perhaps it would be used more often than the
"set_attribute" functions currently are?

 -PD

-- 
--
Patrick Doyle
doylep@ecf.utoronto.ca

Re: Visibility and access to "public" attributes

[Nick Leaton]

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.

Re: Visibility and access to "public" attributes

[Nick Leaton]

Gavin Collings wrote:
> 
> Nick Leaton <nickle@calfp.co.uk> wrote in article
> <34101640.8CF27E0@calfp.co.uk>...
> >
> > 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.
> 
> Yes, 1 in every 5-6 classes is quite low, but not insignificant.  I would
> imagine from the number of classes in the sample that a good representative
> cross section of application was caught.  I'm sure the reason you're
> pointing to is at least a significant factor.  In fact (as we found out on
> a circle-ellipse discussion over on comp.object recently) any modifying
> operation which can produce an invariant violating state change in an
> object gives problems.  Direct attribute writes certainly fall into that
> category more often than other more benign operations.

It is actually much lower than that. If I count the number of classes
containing the set attribute features it comes to 48. (They have more
than one set attribute
feature). The ratio is very low.

> > 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.
> 
> And a very elegant paradigm it is too.
> 
> > Since your object is now created, there tend to be fewer attributes that
> > you want to set once it has been created.
> 
> Especially if the syntax involved isn't especially sweet, and excessive
> amounts of typing are involved ;-)

Lets save our fingers! ;-)

-- 

Nick

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