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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,72c34c66b38e0e05 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-01-03 05:20:30 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!headwall.stanford.edu!fu-berlin.de!uni-berlin.de!dialin-145-254-037-071.arcor-ip.NET!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Proposal: Constructors, Assignment [LONG] Date: Fri, 03 Jan 2003 14:20:57 +0100 Organization: At home Message-ID: References: Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: dialin-145-254-037-071.arcor-ip.net (145.254.37.71) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Trace: fu-berlin.de 1041600029 12211719 145.254.37.71 (16 [77047]) User-Agent: KNode/0.7.1 Xref: archiver1.google.com comp.lang.ada:32486 Date: 2003-01-03T14:20:57+01:00 List-Id: Randy Brukardt wrote: > Dmitry A. Kazakov wrote in message ... >>Randy Brukardt wrote: >>> Dmitry A. Kazakov wrote in message ... >>>>Randy Brukardt wrote: >>>>> The basic idea is to somehow figure a value of Ada.Tags.Tag, then > use >>> it >>>>> to control dispatching on a function that returns the correct kind > of >>>>> object. This requires a special call: >>>>> >>>>> Obj : T'Class := Func () use Tag_Value; >>>> >>>>The question is, will dispatching without an object be useful in > cases other >>>>than construction? >> >>Why this sort of syntax was chosen? > > I chose it only because it has a natural, cheap, and obvious > implementation. I was hoping someone would have a better suggestion (but > that turned out to be "kill the idea"). > >>I think more consequently in Ada's >>spirit would be sort of: >> >> Obj : T'Class (Tag_Value) := Func (); >> >>Isn't tag a natural constraint/discriminant of T'Class? > > Yes, but this doesn't work, because you don't know the discriminants for > the object. I need not know them. The call to Func has to be dispatching, so the function will return all discriminants. It should work exactly as Obj : T'Class := Func () use Tag_Value; > Indeed, you don't even know how many there are or their > types (since you can change the discriminants on extensions, including > adding or removing them), so you can't even give them if you want to. Yes, so the type T'Class (Tag_Value) should be made indefinite to prevent object declarations like: Obj : T'Class (Tag_Value); Or do you think that things like: procedure Foo1 (X : T'Class) is procedure Foo2 (Y : T'Class (X'Tag)) is ... could become a problem? >>BTW. Why not to allow tag comparisons >, >=, <, <=? I mean: >> >> function ">" (Left, Right : Tag) return Boolean; >> >>A>B if B is a descendant of A, but not of A type. > > These certainly are allowed if you write them yourself. How? I think they should be predefined for all tags along a path in a type tree. If they of different paths, Constraint_Error have to propagate. > Even if you had > them, you still need a way to control the dispatching based on the > result (once you've figured out the LCD). Not always. I have in mind simulation of multiple dispatch for binary operations. I could declare one as: function "+" (Left : T; Right : T'Class) return T'Class; Should I have "<=" for tags to figure out which argument is closer to T an implementation could be very straightforward: type New_T is new T with private; function "+" (Left : New_T; Right : T'Class) return T'Class is begin if Right'Tag <= New_T'Tag then -- Right is closer to T than Left or same as Left declare Result : New_T := ...; begin ... -- Sum a New_T and one of its ancestors return Result; end; else -- Right is more closer to T than Left return Right = Left; -- Dispatch on Right end if; end "="; There is a work-around using "in", but it is nasty because it requires a hidden parameter to prevent infinite recursion. -- Regards, Dmitry A. Kazakov www.dmitry-kazakov.de