Re: Ada OOP question

[mark_lundquist@my-deja.com]

In article <3A35B45D.5F05F171@acm.org>,
  Jeff Carter <jrcarter@acm.org> wrote:
>
> You have presented no evidence to support your claim of baloney.
Salami,
> perhaps.

:-)

>
> Seriously, I was employing hyperbole in describing it as EVIL.
However,
> I think that this practice should be discouraged. The problem is that
> such a type creates an interface that is difficult to understand. What
> is the difference between
>
> Op (Object, Param1, Param2);
>
> and
>
> Object.Public_Component := Some_Value;
> Op (Object, Param1, Param2);
>
> ? They could be the same; Op could perform differently in the 2nd
case,
> but this be considered valid; or Op could be invalid as a result of
the
> assignment.

Sure... but this observation is just as valid if you replace the
assignment to the public component with any operation.  Since
encapsulation isn't relevant to your observation, the observation isn't
a sound argument for encapsulation in general nor against mixing public
and private components in particular.  (Don't get me wrong, I'm all for
encapsulation, this just isn't the argument for it! :-)  Your argument
below, viz. coupling to the implementation, is much more to the point...

>
> This doesn't bother C++ people, who expect the client to read the
> implementation to learn how to use a type.
>

True enough, it's the "header file" heritage.  In C you often find a
function's documentation comments in the .c file, while the .h file
(ostensibly the "interface") is just "extern blah blah(blah, blah);" on
everything, with no comments.

> Frequently such components
> are used both to shorten parameter lists and store state between
calls.
>
> In general, visible components in an abstraction are a bad idea,
> including when they are all visible: you cannot change the
> implementation without changing the interface.

There you go, that has always seemed to me to be the "real" argument.

I wonder if the reason people sometimes use public components instead
of accessors/mutators (or getters/setters or whatever you want to call
them) because they are trying to "optimize performance".  Certainly in
C++ it's well known that member functions defined in the class
definition are inlined, but maybe people don't know that you can inline
subprograms in Ada (Rational's compiler does auto-inlining when
optimization is turned on, and its algorithm is quite difficult for a
human programmer to beat in terms of final executable speed and size).
Don't know about inlining in Java...

Mark Lundquist
Rational Software


Sent via Deja.com
http://www.deja.com/