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,1116ece181be1aea X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-09-22 07:33:29 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!in.100proofnews.com!in.100proofnews.com!attla2!ip.att.net!attbi_feed3!attbi.com!rwcrnsc54.POSTED!not-for-mail Message-ID: <3F6F0841.60607@attbi.com> From: "Robert I. Eachus" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Is the Writing on the Wall for Ada? References: <568ede3c.0309160929.1d0d3d95@posting.google.com> <3F67AFB9.7040001@attbi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit NNTP-Posting-Host: 24.34.139.183 X-Complaints-To: abuse@comcast.net X-Trace: rwcrnsc54 1064241205 24.34.139.183 (Mon, 22 Sep 2003 14:33:25 GMT) NNTP-Posting-Date: Mon, 22 Sep 2003 14:33:25 GMT Organization: Comcast Online Date: Mon, 22 Sep 2003 14:33:25 GMT Xref: archiver1.google.com comp.lang.ada:42748 Date: 2003-09-22T14:33:25+00:00 List-Id: I said: > there is no reason to do explicit casting Hyman Rosen wrote: > Except when there is. These kinds of situations arise when objects are > held in containers, passed around through various pieces of code not > necessarily under your control, and finally handed back to your code. > The object comes in as a pointer to some class, and the situation may > arise when you need to know whether the object is of some other class > type as well. The dynamic_cast will safely tell you, (almost) regardless > of how the two classes are arranged in the inheritance hierarchy of the > most derived type. > > This is a moot point in Ada right now, since Ada just has SI. When the > access discriminant style is used, this cross-casting is impossible > unless you go back to the base type first, which means that code which > in C++ would know only about the two interface types must in Ada be aware > of the containing type as well. No, it is not a moot point in Ada. You can create containers for classwide types, and you may want to use an operation only valid for a subclass of that class. But as I said: > If you say (using my code): > Set(Some_Object, Red); -- where Red is a value of type Color. > you would get exactly the same result as if you said: > Set(My_Colors.Colored_Object(Some_Object), Red); In this case if say the code was: declare Some_Object: Nothing'Class := Pop(Some_Stack); -- where Nothing is my -- original base class and Pop is for some Stack class instantiated -- for Nothing'Class. begin Set(Some_Object, Red); ... exception when Constraint_Error => Put_Line("Not a member of My_Color'Class."); when Program_Error => Put_Line("Oops"); -- there are potential cases. end; Again I could do the explicit cast, but why? The view conversion will raise Constraint_Error if it fails. Actually, there might be a case where I wanted to walk a subtree changing colors for objects that had them. Then it would be more appropriate to do: declare Some_Object: Nothing'Class := Next(Some_Tree_Iterator); begin if Some_Object in My_Color'Class then Set(Some_Object, Red); end if; end; With the current interface proposal, you could even say "if Some_Object in Colored_Object'Class..." and it would do the correct check for several different potential instances of Colors that are subclasses of Nothing. The call on Set will work or raise Constraint_Error (or Program_Error) for either the interface approach or the mix-in approach. But notice what is going on here. In the cases where "true" multiple inheritance can't work, Ada resolves the ambiguity based on the parameter and result profile, the mix-in order, allows the user to directly resolve the overloading, or raises an error. (Program_Error is possible in some cases, such as the call being made where the routine is at the wrong accessability level. Not a problem unless you instantiate generics inside subprograms, and aren't careful.) In many cases where other languages that support MI will barf, there is no problem in Ada. That was the whole point of my overloading Set and Get. Since Ada looks at the whole profile when doing overload resolution, not just the name, you can do this and it will "just work," even though a concrete type can inherit dozens of Get and Set operations from different classes. -- Robert I. Eachus Ryan gunned down the last of his third white wine and told himself it would all be over in a few minutes. One thing he'd learned from Operation Beatrix: This field work wasn't for him. -- from Red Rabbit by Tom Clancy.