Access to function returning class-wide type

Dmitry A. Kazakov wrote:

> So you could replace it with a map condition->type tag and then proceed
> with Ada.Tags.Generic_Dispatching_Constructor, because the map
> tag->constructor is for free, here you do not need pointers any more, in
> Ada 2005. The compiler will force to override the "constructor" for each
> concrete derived type.
> -------------
> Having said that, there still is a difficult problem with construction of
> the map. I don't know if it is an issue for you, but it is for the
> persistency layer I designed. The problem is that if the map is
> open-ended, you need some mechanism of registration of each new type in
> the map. This is still unresolved in Ada. The pattern I am using is that
> each package declaring a new type is required to call some class-wide
> procedure registering the type upon package elaboration. In your case it
> is the condition associated with the type tag. That cannot be enforced,
> and it works only at the library level, i.e. for "immortal" types.

I think that the map condition->type tag is in my case same problem as map
condition->constructor pointer. I need the map registration anyway, because
it basically needs to be changed at run-time. Altrough, all the types I
need to register are library-level types, so the registration mechanism is
pretty simple.

> A possible solution in the future language revisions could be to introduce
> type constructors/destructors: user-defined procedures called upon
> derivation and leaving the scope of a type.

I can't wait to see that :-)

--
Pawe³ P³azieñski aka Nivertius
"In the end, there will be Ada, XML and gzip"

On Thu, 21 Aug 2008 21:30:28 +0200, Pawe³ 'Nivertius' P³azieñski wrote:

> Dmitry A. Kazakov wrote:
>
>> So you could replace it with a map condition->type tag and then proceed
>> with Ada.Tags.Generic_Dispatching_Constructor, because the map
>> tag->constructor is for free, here you do not need pointers any more, in
>> Ada 2005. The compiler will force to override the "constructor" for each
>> concrete derived type.
>> -------------
>> Having said that, there still is a difficult problem with construction of
>> the map. I don't know if it is an issue for you, but it is for the
>> persistency layer I designed. The problem is that if the map is
>> open-ended, you need some mechanism of registration of each new type in
>> the map. This is still unresolved in Ada. The pattern I am using is that
>> each package declaring a new type is required to call some class-wide
>> procedure registering the type upon package elaboration. In your case it
>> is the condition associated with the type tag. That cannot be enforced,
>> and it works only at the library level, i.e. for "immortal" types.
>
> I think that the map condition->type tag is in my case same problem as map
> condition->constructor pointer. I need the map registration anyway, because
> it basically needs to be changed at run-time.

Why then N is a parameter? When each type knows its N you don't need to
pass it back.

> Altrough, all the types I
> need to register are library-level types, so the registration mechanism is
> pretty simple.

Then the pattern is (assuming N is unknown in advance):

package A is
type Abstracted is abstract tagged null record;
procedure Register
( N : out Natural; -- Given upon registration
Constructor : not null access
function return Abstracted'Class
);
end A;

package B is
type Derived is new Abstracted with ...;
end B;

package body B is
My_N : Natural;

function Create return Abstracted'Class is
begin
return Derived'(...); -- Returns derived
end Create;

begin
Register (My_N, Create'Access);
end B;

You don't need to declare Create in A at all. Each type will declare it in
order to call to Register anyway.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:tslrrr8w3j63.zp28ykzgmr23.dlg@40tude.net...
....
> P.S. I don't know reasons why it was decided to use an access type in
> Ada.Tags.Generic_Dispatching_Constructor profile. One could always pass a
> pointer there if a side effect on the parameters were desired. But that is
> another issue, and in any case Proc is thought as an implementation
> detail,
> so its exact profile should not really matter.

I originally came up with this proposal (based on random thoughts tossed out
by Steve Baird and Tucker Taft). We'd been trying to find solutions for
literally years; I was amazed that this one didn't fall into a heap of slag
as the others had.

Anyway, the access parameter exists so that an instance of this routine
matches the profile of S'Class'Input. After all, the purpose of this routine
is to eliminate the Ada 95 compiler magic involved with S'Class'Input and
make it user-programmable. The thought is that a user-defined version of
S'Class'Input would be directly specified as an instance of
Generic_Dispatching_Constructor.

In hindsight, I'm not certain that is a good idea, because it mucks up the
spec for no particularly good reason. But that's the way it is now.

Randy.

Dmitry A. Kazakov wrote:

> Why then N is a parameter? When each type knows its N you don't need to
> pass it back.

To be perfectly honest, the parameter in my specific case is not a Natural
[it was just an example], but complex type. Type of the produced object is
determined on one part and the distinct type is built on the whole object.
Sorry for misleading you, but for natural it also can be the case:
When the condition is N in 1 .. 12, type should be Derived_1 build on that
N.

--
Pawe³ P³azieñski aka Nivertius
"In the end, there will be Ada, XML and gzip"

"Randy Brukardt" <randy@rrsoftware.com> wrote in message
news:g8lgof$54c$1@jacob-sparre.dk...
....
> Anyway, the access parameter exists so that an instance of this routine
> matches the profile of S'Class'Input. After all, the purpose of this
> routine is to eliminate the Ada 95 compiler magic involved with
> S'Class'Input and make it user-programmable. The thought is that a
> user-defined version of S'Class'Input would be directly specified as an
> instance of Generic_Dispatching_Constructor.

I realized just now that I screwed up this answer, it doesn't make much
sense as I wrote it above. The correct reason was so that S'Input could be
used as the constructor routine to an instance of
Generic_Dispatching_Constructor, and then that instance could be used as
part of a routine implementing a user-defined S'Class'Input. Sorry about any
confusion.

Randy.