comp.lang.ada
 help / color / mirror / Atom feed
From: "Randy Brukardt" <randy@rrsoftware.com>
Subject: Re: Proposal: Constructors, Assignment [LONG]
Date: Thu, 2 Jan 2003 13:36:56 -0600
Date: 2003-01-02T13:36:56-06:00	[thread overview]
Message-ID: <v1955k94k1ts10@corp.supernews.com> (raw)
In-Reply-To: auut24$aa0ff$2@ID-77047.news.dfncis.de

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 (<args>) 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 (<args>);
>
>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. 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.
People would have prefered this sort of solution, but it just doesn't
work.

>> Yes, I think so. Two other examples have come up:
>>   -- Calling the parent operation (which Ada does not have any
>> convinient syntax for - currently you have to name the parent
>> explicitly, which is a source of bugs);
>
>Yes it would be nice. However you will need something to get a parent's
type
>tag from the type tag.

I proposed an attribute for that purpose: T'Parent_Tag. For Janus/Ada,
the parent tag is stored in every tag, so this operation is very cheap.
However, there were concerns about the fact that there are potentially
two (related) parents for every type: the parent of the partial view and
the parent of the full view. I think the attribute has to go to the
parent of the full view, and since it is dynamic, the "privateness
breaking" of that is not a real concern.

>>   -- Handling "least common denominator" comparison.
>
>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. 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).

         Randy.






  reply	other threads:[~2003-01-02 19:36 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-12-24 11:16 Proposal: Constructors, Assignment [LONG] Dmitry A. Kazakov
2002-12-26 22:11 ` Nick Roberts
2002-12-27 17:43   ` Dmitry A. Kazakov
2002-12-27 20:17     ` Randy Brukardt
2002-12-29 13:43       ` Dmitry A. Kazakov
2002-12-29 18:45         ` Nick Roberts
2002-12-30 12:23           ` Dmitry A. Kazakov
2002-12-30 15:14             ` Robert A Duff
2002-12-31 13:02               ` Dmitry A. Kazakov
2003-01-01  0:28                 ` Randy Brukardt
2003-01-01 14:13                   ` Dmitry A. Kazakov
2003-01-02 19:44                     ` Randy Brukardt
2003-01-03 13:21                       ` Dmitry A. Kazakov
2003-01-03 19:29                         ` Randy Brukardt
2003-01-03 20:50                       ` Robert A Duff
2003-01-04 12:53                         ` Dmitry A. Kazakov
2003-01-01  0:54         ` Randy Brukardt
2003-01-01 14:13           ` Dmitry A. Kazakov
2003-01-02 19:36             ` Randy Brukardt [this message]
2003-01-03 13:20               ` Dmitry A. Kazakov
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox