Re: Ada OOP question

Re: Ada OOP question

[Randy Brukardt]

James S. Rogers wrote in message ...

>The question clearly comes from a person who has learned C++ or Java.
>Those languages allow classes to be defined with mixtures of public and
>private data.
>
>The same effect can be achieved in Ada, although the syntax is not as
clean
>as in C++ or Java.
>
>A tagged type in Ada is defined either in the public or private area of
a
>package specification. It is not defined partially in the public area
and
>partially in the private area. At first glance this seems to forbid
creating a
>tagged type with both public and private data members. There is a
solution.
>
>In Ada you need to extend the inheritance hierarchy a little deeper to
>achieve your goals.  Follow these steps:
>
>1) Declare a tagged type in the public part of a package specification.
>2) Extend that tagged type with a private extension in the private part
of a
>    child package specification.
>3) Inherit all future tagged types in that class from the child package
with the
>    private definition.

It's not necessary to create a separate package for the extension (IF
you're careful with the placement of primitive operations). This is an
important difference between C++ and Ada (since the encapsulation and
inheritance mechanisms are separate in Ada).

If your only purpose is to have both kinds of components, make the
original type abstract so no one can accidentally create an object of it
(without the private components):

(We use this technique in Claw to hide locks associated with some
objects...)

package Employee_Package is
   type Public_Employee is abstract tagged record -- No objects of this
are allowed.
      Name : String(1..30);
      Age    : Positive;
      Employee_Id : String(1..8);
      Title   :  String(1..20);
  end record;


  type Employee is new Public_Employee with private;

 -- Follow with public subprograms appropriate to
 -- the above tagged type definition


private
   type Employee is new Public_Employee with record
      Salary : Float;
   end record;
end Employee_Package;

>Every instance of the Employee tagged type, or any instance in its
>class hierarchy, will have both public and private data members.


            Randy Brukardt
            R.R. Software, Inc.

Re: Ada OOP question

[Jeff Carter]

mark_lundquist@my-deja.com wrote:
> Baloney!  How is mixing public and private any more EVIL than having
> all components public, which Ada makes no more difficult than any other
> language?  Arguably, if one feels that some component of an abstraction
> must be public, it's still better to have the rest private than to make
> all public, wouldn't you say?  I think one could make a case that
> public components in general are about the same level of evilness as
> goto, i.e. easy to abuse, but also easy enough not to abuse, and the
> abuse is of a kind that is more a consequence of bad design than a
> cause.

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.

This doesn't bother C++ people, who expect the client to read the
implementation to learn how to use a type. 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.

-- 
Jeff Carter
"I blow my nose on you."
Monty Python & the Holy Grail

Re: Ada OOP question

[mark_lundquist]

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/

Re: Ada OOP question

[Jeff Carter]

mark_lundquist@my-deja.com wrote:
> > 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...

I disagree. If I write the package with no public components, I can
easily detect invalid sequences of operations. I can often prevent
invalid sequences of operations. This is less easy when one of the
operations is direct assignment to components of the 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.

Too frequently there are no comments anywhere. The code is "self
documenting".

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

"Performance" is often used as an excuse for bad design. "We have this
variable in the package spec for performance reasons."

"Really? Where are the performance requirements documented? Where are
the results of timing tests without the global variable documented?"

"Well, there aren't any. I just know it will be too slow otherwise."

Such claims are rarely true.

-- 
Jeff Carter
"I waggle my private parts at your aunties."
Monty Python & the Holy Grail

Re: Ada OOP question

[Stephen Leake]

hdhil@aol.com (HDhil) writes:

> Simple question re Ada OOP: Does Ada 95 allow
> the specification of public components? 

One solution is:

package My_Package is

    type My_Object_Private is private;

    type My_Object is record
        public_1 : foo;
        public_2 : bar;
        private_1 : My_Object_Private;
    end type;

private
    type My_Object_Private is record
        private_stuff : foo_bar;
    end record;
end My_Package;

Clients of this package can copy private_1, but can't examine inside
it. If copying is bad, use a limited private type.

-- 
-- Stephe