Re: Visibility and access to "public" attributes

[doylep@ecf.toronto.edu (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