From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: fac41,8ff80a74f45b5cd3
X-Google-Attributes: gidfac41,public
X-Google-Thread: 103376,8ff80a74f45b5cd3
X-Google-Attributes: gid103376,public
From: doylep@ecf.toronto.edu (Patrick Doyle)
Subject: Re: Visibility and access to "public" attributes
Date: 1997/08/29
Message-ID: <EFotFL.I5t@ecf.toronto.edu>#1/1
X-Deja-AN: 268967154
X-Nntp-Posting-Host: skule.ecf
Sender: news@ecf.toronto.edu (News Administrator)
References: <872873007.3110@dejanews.com>
Organization: University of Toronto, Engineering Computing Facility
Newsgroups: comp.lang.ada,comp.lang.eiffel
Date: 1997-08-29T00:00:00+00:00
List-Id: <comp.lang.ada>


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