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.9 required=5.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.4
X-Google-Thread: 103376,f93e461e8491e322,start
X-Google-Attributes: gid103376,public
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news2.google.com!news3.google.com!news4.google.com!news.glorb.com!solnet.ch!solnet.ch!news-zh.switch.ch!switch.ch!cernne03.cern.ch!not-for-mail
From: Maciej Sobczak <no.spam@no.spam.com>
Newsgroups: comp.lang.ada
Subject: Limited_Controlled, orthogonality and related issues
Date: Thu, 18 Jan 2007 10:24:53 +0100
Organization: CERN News
Message-ID: <eoned5$663$1@cernne03.cern.ch>
NNTP-Posting-Host: abpc10883.cern.ch
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-2; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: cernne03.cern.ch 1169112293 6339 137.138.37.241 (18 Jan 2007 09:24:53
 GMT)
X-Complaints-To: news@@cern.ch
NNTP-Posting-Date: Thu, 18 Jan 2007 09:24:53 +0000 (UTC)
User-Agent: Thunderbird 1.5.0.9 (X11/20061220)
Xref: g2news2.google.com comp.lang.ada:8248
Date: 2007-01-18T10:24:53+01:00
List-Id: <comp.lang.ada>

Hi,

Consider the following problem:

package P is
    type T is limited private;
    type S is limited private;
    procedure Do_The_Job(X : in T; Y : in S);
    -- and gazillion of other subprograms like Do_The_Job
private
    -- ...
end P;

At some point I decide to add automatic destruction to T and S, so the 
package becomes:

with Ada.Finalization;
package P is
    type T is limited private;
    type S is limited private;
    procedure Do_The_Job(X : in T; Y : in S);
    -- and gazillion of other subprograms like Do_The_Job
private
    type T is new Ada.Finalization.Limited_Controlled with -- ...
    type S is new Ada.Finalization.Limited_Controlled with -- ...
end P;

Suddenly, the package no longer compiles:

"operation can be dispatching in only one type"

By making T and S controlled types, they became tagged and Do_The_Job is 
now incorrect.

First observation:
My design decision to make T and S controlled has absolutely nothing to 
do with Do_The_Job. It relates to those scopes where te objects are 
created, not to those where they are used. It looks that my decision 
affects unrelated parts of the pacakge (Do_The_Job and there are 
gazillions of such subprograms), which is non-sense. There is something 
wrong.

OK, I'm determined to get it done. I do this:

    procedure Do_The_Job(X : in T'Class; Y : in S'Class);

(one would be enough, but let's be symmetric)

Thanks to this, Do_The_Job is no longer dispatching (it was never 
supposed to be, by the way!).

But wait, now there's another problem:

"tagged type required"

It looks like the compiler pretends it doesn't know that T is tagged.

Second observation:
The compiler does know that T and S are tagged, because it is exactly 
what prevented it to compile Do_The_Job in its original form.
Now it pretends it has no idea that T and S are tagged, which is 
non-sense number two. Something's completely wrong here.

But I'm really determined to get it done. I do this:

    type T is tagged limited private;
    type S is tagged limited private;
    procedure Do_The_Job(X : in T'Class; Y : in S'Class);
    -- and gazillion of other subprograms like Do_The_Job

So, my simple decision to make T and S controlled required:

1. Changing the signatures of Do_The_Job and gazillion of similar 
subprograms.
2. Adding the tagged keyword in the public view for T and S.

In conclusion, my decision to make T and S controlled appeared to not be 
orthogonal to the rest of the package.

What are your thoughts about this?

Most importantly: why I had to add the tagged keyword?

-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/