How to overload assignment in Ada 95?

How to overload assignment in Ada 95?

[Christopher D Carothers]

	In 7.6 of the Ada95 LRM, it talks about
user-defined assignment. Could someone please 
provide me with an example of how I would in fact
"overload" the assignment operator for a particular
package. The LRM talks about the Ada.Finalization
package and the the "Adjust" procedure. However,
it does not give an example of how I would use
this package to achieve the "overloading" of assignment.

		Thanks,
		-- Chris

-- 
Christopher D Carothers
Georgia Institute of Technology, Atlanta Georgia, 30332
uucp:	  ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!cc!chrisc
Internet: chrisc@cc.gatech.edu

Re: How to overload assignment in Ada 95?

[Robert Dewar]

Chris asks

"        In 7.6 of the Ada95 LRM, it talks about
user-defined assignment. Could someone please
provide me with an example of how I would in fact
"overload" the assignment operator for a particular
package. The LRM talks about the Ada.Finalization
package and the the "Adjust" procedure. However,
it does not give an example of how I would use
this package to achieve the "overloading" of assignment."


There is user-defined assignment in Ada 95, but you are making the jump
to assume that this means that the assignment "operator" can be overloaded.
It cannot, only operators and subprograms can be overloaded, and assignment
is neither, it is an operation, but not an operator.

Generally it is pretty hopeless to expect to learn how to use features like
this from the RM. In particular, the examples in the RM (which I actually
consider to be annoying redundancy), are not intended to be anything like
a complete learn-by-example set.

Any reasonably comprehensible Ada text, e.g. Barnes or Cohen, will explain
a feature like this in detail with lots of examples, and you will find this
a much more practical way of learning how features like this work. Then the
RM can be used as a reference source once you have a basic understanding.

I asked at Tri-Ada the other day how many people had learned Ada 95 from
the RM. In a room of several hundred people, only four or five put up
their hands (Tucker Taft was one of them :-)

I also asked how many used the RM for reference purposes, and there well
over half put up their hands, which is as one would expect.

It is very important to understand what the RM is and what it is not. It
is NOT a document for learning the language, and it is not a document
that you can expect to be able to read easily without a lot of experience
in language definitions.

The confusion can particularly arise in the case of the Ada RM, since 
unlike some other language definitions (e.g. the Algol-68 report, or the
ANSI PL/1 definition), it has the form of a normal text, and is muuch
more accessible than a typical formal definition. This is valuable in that it makes
it more useful as a reference source to more people, but you must not mistake
this for implying that it is a text book, it is not :-) Furthermore, the
Ada 95 RM has moved further away from text book mode, and further towards
formal definition, so these comments apply even more srtongly to the Ada 95
RM.

As an example of the difference. In a text book, it is often desirable to
state things redundantly. If you state A and state B, and it is the case
that A and B together obviously imply C, then it is still a good idea often
in a text book to state C, especially if A and B are far apart and in
non-obvious places. But in a formal definition, it is redundant to state
C, and thus undesirable, since if you do state C, you run the risk of
stating it in inconsistent form.

The Ada 95 RM (unlike true formal definitions) is not *quite* so hard nosed,
and the notes and examlples (which are all redundant information, and indeed
occasionally run the risk of being wrong, and hence actively unuseeul) are
not part of the standard, but do help some people read it (as I said earlier,
for my own taste I dislike the examples in the RM, and have never read any
of them, but I understand that most people find them helpful, but the risk
is that they expect them to be complete -- they are not!)

Re: How to overload assignment in Ada 95?

[Brad Balfour]

In article <58aclh$ssd@gaia.cc.gatech.edu>, chrisc@cc.gatech.edu
(Christopher D Carothers) wrote:

>        In 7.6 of the Ada95 LRM, it talks about
>user-defined assignment. Could someone please 
>provide me with an example of how I would in fact
>"overload" the assignment operator for a particular
>package. The LRM talks about the Ada.Finalization
>package and the the "Adjust" procedure. However,
>it does not give an example of how I would use
>this package to achieve the "overloading" of assignment.

I wrote up an example of this for an article in ACM SIGAda's Ada Letters
magazine in Vol. XIV, No. 5, September/October, 1994.
An online copy of this article can be found at:
http://www.acm.org/~bbalfour/tips_no_1.html

I hope this helps,
Brad

-- 
Brad Balfour                            SIGAda WWW Server
CACI, Inc.                                http://www.acm.org/sigada/
(703) 277-6767                          and also try:
bbalfour@std.caci.com                     http://www.adahome.com/
address: 3930 Pender Drive * Fairfax, VA 22030

Re: How to overload assignment in Ada 95?

[Matthew Heaney]

In article <bbalfour-0912961334030001@stmac0088.std.caci.com>,
bbalfour@std.caci.com (Brad Balfour) wrote:

>In article <58aclh$ssd@gaia.cc.gatech.edu>, chrisc@cc.gatech.edu
>(Christopher D Carothers) wrote:
>
>>        In 7.6 of the Ada95 LRM, it talks about
>>user-defined assignment. Could someone please 
>>provide me with an example of how I would in fact
>>"overload" the assignment operator for a particular
>>package. The LRM talks about the Ada.Finalization
>>package and the the "Adjust" procedure. However,
>>it does not give an example of how I would use
>>this package to achieve the "overloading" of assignment.
>
>I wrote up an example of this for an article in ACM SIGAda's Ada Letters
>magazine in Vol. XIV, No. 5, September/October, 1994.
>An online copy of this article can be found at:
>http://www.acm.org/~bbalfour/tips_no_1.html

Does anyone have a rule of thumb for when a controlled type should publicly
derive from type Ada.Finalization.Controlled?  For example

with Ada.Finalization;
...
package Unbounded_Stacks is

   type Unbounded_Stack is new Ada.Finalization.Controlled with private;
...

versus

with Ada.Finalization;
...
package Unbounded_Stacks is

   type Unbounded_Stack is private;
...
private

   type Unbounded_Stack is new Ada.Finalization.Controlled with
      record ... end record;
...

In the former case, clients of the Unbounded_Stack have direct visibility
to the operations Initialize, Finalize, and Adjust.  When is this a good
thing?  A bad thing?

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
mheaney@ni.net
(818) 985-1271

Re: How to overload assignment in Ada 95?

[Robert A Duff]

In article <mheaney-ya023280000912962054110001@news.ni.net>,
Matthew Heaney <mheaney@ni.net> wrote:
>In the former case, clients of the Unbounded_Stack have direct visibility
>to the operations Initialize, Finalize, and Adjust.  When is this a good
>thing?  A bad thing?

It is a good thing if you want people to be able to extend the type --
they will override Finalize and friends (and the new version should call
the parent version).  If you don't want that, or want to restrict such
type extensions to child packages, then use the second method.

- Bob

Re: How to overload assignment in Ada 95?

[Brad Balfour]

In article <mheaney-ya023280000912962054110001@news.ni.net>,
mheaney@ni.net (Matthew Heaney) wrote:
[snip]
>Does anyone have a rule of thumb for when a controlled type should publicly
>derive from type Ada.Finalization.Controlled?
[snip]
>In the former case, clients of the Unbounded_Stack have direct visibility
>to the operations Initialize, Finalize, and Adjust.  When is this a good
>thing?  A bad thing?

This exact question was dealt with in the next two articles in the Tips &
Tidbits series (see <http://www.acm.org/~bbalfour/tips_and_tidbits.html>):

 Number 2: Expressing Design Inheritance Relationships in Ada 95,
   published in Ada Letters, Vol. XV No. 3, May/June, 1995. 
         <http://www.acm.org/~bbalfour/tips_no_2.html>
 Number 3: Inheritance and Child Library Units, published in Ada
      Letters, Vol. XV No. 4, July/August, 1995.
         <http://www.acm.org/~bbalfour/tips_no_3.html>

There are actually two separate issues/trade-offs:
1) A visible extension vs a private extension of the parent and
2) Derivation in the visible part vs. a private type and derivation
    in the private part.
The above two articles discuss when each technique is appropriate.

However, one conclusion has become fairly obvious in retrospect. If
overridings of Adjust, Finalize and Initialize are provided in the visible
part, then it is possible for clients to call them directly -- a situation
that is *not* desireable. Therefore, I now recommended that the overriding
declarations appear in the private part. However, moving the overridings
to the private part opens the (small) possiblity that the type declaration
becomes frozen prior to these declarations. If this were to happen, the
compiler would issue an error message. At that point, the developer can
then modify the code to move the declarations prior to the freezing point.

>--------------------------------------------------------------------
>Matthew Heaney
>Software Development Consultant
>mheaney@ni.net
>(818) 985-1271

-- 
Brad Balfour                            SIGAda WWW Server
CACI, Inc.                                http://www.acm.org/sigada/
(703) 277-6767                          and also try:
bbalfour@std.caci.com                     http://www.adahome.com/
address: 3930 Pender Drive * Fairfax, VA 22030
   "...they even have have rules on exceptions" -- Dewar and Schonberg

Re: How to overload assignment in Ada 95?

[Larry Kilgallen]

In article <bbalfour-1012961302000001@stmac0088.std.caci.com>, bbalfour@std.caci.com (Brad Balfour) writes:

> However, one conclusion has become fairly obvious in retrospect. If
> overridings of Adjust, Finalize and Initialize are provided in the visible
> part, then it is possible for clients to call them directly -- a situation
> that is *not* desireable.

If a further derivation is made from the type, and Adjust, Finalize
or Initialize must be overridden by that further derivation, shouldn't
that code call the parental versions to take care of what the parent
knows about ?  Or is this a case where child packages _must_ be used ?

Larry Kilgallen

Re: How to overload assignment in Ada 95?

[Brad Balfour]

In article <1996Dec10.143635.1@eisner>, kilgallen@eisner.decus.org (Larry
Kilgallen) wrote:
>In article <bbalfour-1012961302000001@stmac0088.std.caci.com>,
bbalfour@std.caci.com (Brad Balfour) writes:
>> However, one conclusion has become fairly obvious in retrospect. If
>> overridings of Adjust, Finalize and Initialize are provided in the visible
>> part, then it is possible for clients to call them directly -- a situation
>> that is *not* desireable.

As was pointed out by someone else, I was confusing two different issues
when I wrote this and I am clearly incorrect. Where the overriding occurs
doesn't change the possiblity of calling the operations from client
packages. Sorry.

In article <1996Dec10.143635.1@eisner>, kilgallen@eisner.decus.org (Larry
Kilgallen) wrote:
>If a further derivation is made from the type, and Adjust, Finalize
>or Initialize must be overridden by that further derivation, shouldn't
>that code call the parental versions to take care of what the parent
>knows about ?  Or is this a case where child packages _must_ be used ?

It won't matter. The case we are discussing derives the new type in the
visible part of the package. Since the type is known to be a decendent of
Ada.Finalization.Controlled, the operations can be called. Where they are
overriden is irrelevant. 

If the new type were defined as tagged private and only derived from A.F.C
in the private part, then any further derivation that wanted to call on
the operations inherited from A.F.C would have to be located in a child
package.

FWIW, I happen to like the style which mirrors the inheritance hierarchy
in the child package hierarchy.

Brad

-- 
Brad Balfour                            SIGAda WWW Server
CACI, Inc.                                http://www.acm.org/sigada/
(703) 277-6767                          and also try:
bbalfour@std.caci.com                     http://www.adahome.com/
3930 Pender Drive     Fairfax, VA 22030
   "...they even have have rules on exceptions" -- Dewar and Schonberg

Re: How to overload assignment in Ada 95?

[Larry Kilgallen]

In article <bbalfour-1112961505130001@stmac0088.std.caci.com>, bbalfour@std.caci.com (Brad Balfour) writes:

> If the new type were defined as tagged private and only derived from A.F.C
> in the private part, then any further derivation that wanted to call on
> the operations inherited from A.F.C would have to be located in a child
> package.

For many cases that is delightful, but "frameworks" are often intended
to be extended by clients.

> FWIW, I happen to like the style which mirrors the inheritance hierarchy
> in the child package hierarchy.

But making the derivation public should not prevent one from mirroring
the inheritance in the child package hierarchy.  Even if enforcement
by compiler is not acceptable, clarity is still nice.

Larry Kilgallen

Re: How to overload assignment in Ada 95?

[Brad Balfour]

In article <01bbe6dc$6feb3620$829d6482@joy.ericsson.se>, "Jonas Nygren"
<ehsjony@ehs.ericsson.se> wrote:
>I believe it will not help to put the overriding declarations in the 
>private part - they will be available anyway.

You are right. I was confusing two different issues when I wrote this. Sorry.

-- 
Brad Balfour                            SIGAda WWW Server
CACI, Inc.                                http://www.acm.org/sigada/
(703) 277-6767                          and also try:
bbalfour@std.caci.com                     http://www.adahome.com/
3930 Pender Drive     Fairfax, VA 22030
   "...they even have have rules on exceptions" -- Dewar and Schonberg

Re: How to overload assignment in Ada 95?

[Norman H. Cohen]

Jonas Nygren wrote:

> Of course the down side is that you must resort to child packages to
> create type extensions of T.

Why is that a down side?

-- 
Norman H. Cohen
mailto:ncohen@watson.ibm.com
http://www.research.ibm.com/people/n/ncohen

Re: How to overload assignment in Ada 95?

[Jon S Anthony]

In article <mheaney-ya023280000912962054110001@news.ni.net> mheaney@ni.net (Matthew Heaney) writes:

> Does anyone have a rule of thumb for when a controlled type should publicly
> derive from type Ada.Finalization.Controlled?  For example
> 
> with Ada.Finalization;
> ...
> package Unbounded_Stacks is
> 
>    type Unbounded_Stack is new Ada.Finalization.Controlled with private;
> ...
> 
> versus
> 
> with Ada.Finalization;
> ...
> package Unbounded_Stacks is
> 
>    type Unbounded_Stack is private;
> ...
> private
> 
>    type Unbounded_Stack is new Ada.Finalization.Controlled with
>       record ... end record;
> ...
> 
> In the former case, clients of the Unbounded_Stack have direct visibility
> to the operations Initialize, Finalize, and Adjust.  When is this a good
> thing?  A bad thing?

"Never" (scare quotes just in case there _might_ be some odd case
where it would make sense...)

/Jon

-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: How to overload assignment in Ada 95?

[Brad Balfour]

In article <JSA.96Dec10161923@alexandria>, jsa@alexandria (Jon S Anthony) wrote:

>In article <mheaney-ya023280000912962054110001@news.ni.net>
mheaney@ni.net (Matthew Heaney) writes:
>
>> Does anyone have a rule of thumb for when a controlled type should publicly
>> derive from type Ada.Finalization.Controlled?  For example
[snip] 
>> In the former case, clients of the Unbounded_Stack have direct visibility
>> to the operations Initialize, Finalize, and Adjust.  When is this a good
>> thing?  A bad thing?
>
>"Never" (scare quotes just in case there _might_ be some odd case
>where it would make sense...)

I'd think that a "not so odd" case would be any time that your new
abstraction needed to be used anywhere that any descendent of
Ada.Finalization.Controlled would be expected (i.e., as
Ada.Finalization.Controlled'class). 

This could be via a generic formal parameter (type foo is new
Ada.Finalization.Controlled with private) or via type extension (e.g., a
list whose components are of Ada.Finalization.Controlled'class).

In order to use these, you must be known to be a (visible) extension of
Ada.Finalization.Controlled. A side effect of this is that the three
operations are visible to clients.

Brad

>Jon Anthony
>Organon Motives, Inc.
>Belmont, MA 02178
>617.484.3383
>jsa@organon.com

-- 
Brad Balfour                            SIGAda WWW Server
CACI, Inc.                                http://www.acm.org/sigada/
(703) 277-6767                          and also try:
bbalfour@std.caci.com                     http://www.adahome.com/
3930 Pender Drive     Fairfax, VA 22030
   "...they even have have rules on exceptions" -- Dewar and Schonberg

Re: How to overload assignment in Ada 95?

[Robert A Duff]

Consider the predefined Ada.Strings.Unbounded.  It may well be
implemented as a controlled type (if your implementation doesn't do GC).
We chose to make it private in the RM.  So you can't extend it, and
override Finalize (or call Finalize directly).  I think that makes sense
in this case -- why would you want to extend this type?  You might use
components of this type.  But extending it seems unlikely.  On the other
hand, there are types that should be visibly controlled -- you want to
extend them, and override the Finalize (etc) ops.

- Bob