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-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,ca0cb7cf9847d846
X-Google-Attributes: gid103376,public
From: jvl@ocsystems.com (Joel VanLaven)
Subject: Re: Membership test problem
Date: 1996/10/09
Message-ID: <1996Oct9.194036.26265@ocsystems.com>
X-Deja-AN: 188316391
references: <1996Oct6.040427.23644@ocsystems.com>
 <Dyww20.Esr.0.-s@inmet.camb.inmet.com>
organization: OC Systems, Inc.
newsgroups: comp.lang.ada
Date: 1996-10-09T00:00:00+00:00
List-Id: <comp.lang.ada>


Tucker Taft (stt@houdini.camb.inmet.com) wrote:
[snip]
: The conceptual model is that an expression of a "specific" type does
: not have a "Tag" attribute (RM95 3.9(17-18); AARM 3.9(18.a)); a conversion 
: to a class-wide type is required to make the Tag visible.  This was 
: carried over to membership testing, where an expression of a specific type 
: is only tested against the constraints of the tested type; there
: is no consideration of the tag.  Optimization concerns have nothing
: to do with it.

: Similarly, you can't convert an expression of a specific type directly to 
: some extension of the type; you must first convert to its class-wide type
: to open up the possibility that it might actually "underneath" be
: an object of the extended type.

: Finally, when you call a dispatching operation, if the controlling 
: operand(s) are of a specific type, then the underlying tag of those
: operands is irrelevant -- the call is statically bound based on the
: specific (compile-time) type of the operand(s).

: Hence, as long as you have an expression of a specific type, you
: are basically following Ada 83 rules, and tags are irrelevant.
: The only way you can reveal the underlying tag is to convert
: (explicitly or implicitly) to the class-wide type.

: This is a pretty important principle in the Ada 95 model.
: One side-effect of this model is that if there are no conversions
: to class-wide types anywhere, then tags need not be stored anywhere,
: even if you have type extensions.  Again, this is not an optimization,
: rather part of the basic conceptual model distinguishing specific
: types from class-wide types.

  Interesting.  I missed this whole conceptual framework completely...
The concept seems central to OOP in Ada95 but I guess I either missed
some explanation somewhere or noone told me.  This changes the way I
need to think about object-oriented programming in Ada95.  Is the
intention to make me have to explicitly indicate that I want OO type
things going on like dispatching?  I had previously thought that all
I needed to do to indicate that was declare the type to be tagged.
Now it looks like I need to do that AND put 'class on a large number
of things.  I suppose that makes sense from the point of view of
minimizing the impact of OOP on traditional programmers.  The question
is if this makes sense from the point of view of transferring the
benefits that Ada83 gives to traditional programming to OOP.  Perhaps
it does but for me at least, the question is as yet unanswered.

: : ... This is
: : a case where an error might occur and be hidden from the programmer.  It
: : caught me, I can't explain why it is the way it is, and I would either like
: : for it to be considered as a defect in the language, or for an explanation
: : of why I am wrong.  What I want to do can be done other ways.  According to
: : the LRM, what I did has no meaning whatsoever, X in tag is statically
: : evaluated to false.  

: I don't understand that.  I have lost your original example, so I don't
: know whether X was of specific type "tag".  If it was, then "X in tag"
: is statically true (presuming tag doesn't have constrained discriminants).
: If X is not of specific type "tag", then the membership test is illegal,
: since the type of X neither covers nor is covered by "tag" (4.5.2(3)).

  Sorry, I mis"spoke"... I meant statically evaluated to true.  Consider
it a really bad typo.

[snip]
: Could you repost the original example if you reply to this?

  Ok, for what it's worth, here it is.

package test1 is
   type tag1 is tagged null record;
   function is_tag1 (object : in tag1) return boolean;
end test1;

package body test1 is
   function is_tag1 (object : in tag1)return boolean is
   begin
      return object in tag1;
   end is_tag1;
end test1;

with test1; use test1;
package test2 is
   type tag2 is new tag1 with null record;
end test2;

with text_io; use text_io;
with test2; use test2;
procedure main is
  obj:tag2;
begin
  if is_tag1(obj) then
     put_line("Failed");
  else
     put_line("Passed");
  end if;
end main;

BTW, thank you for the info, it was very helpful and interesting.
-- 
-- Joel VanLaven