* Generic abstracts
@ 1999-11-25 0:00 Lutz Donnerhacke
1999-11-25 0:00 ` Lutz Donnerhacke
1999-11-29 0:00 ` Tucker Taft
0 siblings, 2 replies; 8+ messages in thread
From: Lutz Donnerhacke @ 1999-11-25 0:00 UTC (permalink / raw)
Somebody might remember a unspecific quotation from the reference manual
about prohibiting abstract declarations in generic packages.
In my current developemnt I came across this problem again.
generic
type S (<>) is abstract tagged limited private;
package X is
type T is abstract new S with private;
type T_Class is access all T'Class;
type Bla is limited private;
type Position is private;
procedure Set (B : in out Bla;
E : in T_Class);
function Get (B : in Bla) return T_Class;
generic
with procedure On_Item (E : in out S);
procedure Iterate (B : in Bla);
generic
with function Is_Match (E : in S) return Boolean;
function Find (B : in Bla) return Position;
end X;
I will guarantee this interface (Set/Get) over several implementations.
The na�ve approach fails:
generic
type S (<>) is abstract tagged limited private;
package X is
type T is abstract new S null record;
type T_Class is access all T'Class;
type Bla is abstract tagged limited null record;
procedure Set (B : in out Bla;
E : in T_Class) is abstract;
function Get (B : in Bla) return T_Class is abstract;
generic
with procedure On_Item (E : in out S);
procedure Iterate (B : in Bla) is abstract;
-- ^ missing ';'.
-- Providing a sensless dummy function works.
generic
with function Is_Match (E : in S) return Boolean;
function Find (B : in Bla) return Position is abstract;
-- ^ missing ';'.
-- Providing a dummy function is not possible, because no return value exists.
end X;
The abstract definition should be used to ensure a consistent
inteface. I have two problems:
- A generic procedure which can be missed on implementation.
Raising an exception might be acceptable.
- It is not possible to predefine a body for a generic function.
No return value is available.
Raising an exception does not stop the compiler from requiring
a return value.
Any hints?
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Generic abstracts
1999-11-25 0:00 Generic abstracts Lutz Donnerhacke
@ 1999-11-25 0:00 ` Lutz Donnerhacke
1999-11-29 0:00 ` Tucker Taft
1 sibling, 0 replies; 8+ messages in thread
From: Lutz Donnerhacke @ 1999-11-25 0:00 UTC (permalink / raw)
[I'm doing the Ingrid.�]
* Lutz Donnerhacke wrote:
>In my current developemnt I came across this problem again.
ftp://ftp.iks-jena.de/pub/mitarb/lutz/ada/types/
Classic data structures like List, Hash, ... are usually implemented as a
generic package over an item type. They result in a new component type
containing the items.
This packages embell the items to be managed by a component type.
So it allowes an item to be a member of multiple structures at the same time
without expecting anything special from it.
It should be possible to create a hash and two lists over a set of
unconstraint abstract types containing task components.
YFYI.
\f
1 "Doing the Ingrid" is a common phrase in de.ALL, the international
German speaking usenet groups. It refers to a penetrant girl polluting
some groups by a series of recursive followups.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Generic abstracts
1999-11-25 0:00 Generic abstracts Lutz Donnerhacke
1999-11-25 0:00 ` Lutz Donnerhacke
@ 1999-11-29 0:00 ` Tucker Taft
1999-11-29 0:00 ` Lutz Donnerhacke
1 sibling, 1 reply; 8+ messages in thread
From: Tucker Taft @ 1999-11-29 0:00 UTC (permalink / raw)
Lutz Donnerhacke wrote:
>
> Somebody might remember a unspecific quotation from the reference manual
> about prohibiting abstract declarations in generic packages.
>
> In my current developemnt I came across this problem again.
> ...
> generic
> with procedure On_Item (E : in out S);
> procedure Iterate (B : in Bla) is abstract;
> -- ^ missing ';'.
> -- Providing a sensless dummy function works.
>
> generic
> with function Is_Match (E : in S) return Boolean;
> function Find (B : in Bla) return Position is abstract;
> -- ^ missing ';'.
> -- Providing a dummy function is not possible, because no return value exists.
> end X;
>
> The abstract definition should be used to ensure a consistent
> inteface. I have two problems:
> - A generic procedure which can be missed on implementation.
> Raising an exception might be acceptable.
> - It is not possible to predefine a body for a generic function.
> No return value is available.
> Raising an exception does not stop the compiler from requiring
> a return value.
>
> Any hints?
I'm unclear as to what you are trying to accomplish by including
generic subprograms that are abstract. Generic subprograms are
not inherited, so there is no point in declaring them on an
abstract type.
Perhaps if you showed how the generic package was going to be
instantiated and used, I might be able to suggest a solution to
your problem.
--
-Tucker Taft stt@averstar.com http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.) Burlington, MA USA
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Generic abstracts
1999-11-29 0:00 ` Tucker Taft
@ 1999-11-29 0:00 ` Lutz Donnerhacke
1999-11-29 0:00 ` Tucker Taft
0 siblings, 1 reply; 8+ messages in thread
From: Lutz Donnerhacke @ 1999-11-29 0:00 UTC (permalink / raw)
* Tucker Taft wrote:
>Lutz Donnerhacke wrote:
>> The abstract definition should be used to ensure a consistent
>> interface. I have two problems:
>> - A generic procedure which can be missed on implementation.
>> Raising an exception might be acceptable.
>> - It is not possible to predefine a body for a generic function.
>> No return value is available.
>> Raising an exception does not stop the compiler from requiring
>> a return value.
>
>I'm unclear as to what you are trying to accomplish by including
>generic subprograms that are abstract. Generic subprograms are
>not inherited, so there is no point in declaring them on an
>abstract type.
with Abstract_Lists;
generic
type Item (<>) is abstract tagged limited private;
package Concrete_Lists is
package Abstract_Template is
new Abstract_Lists (Item => Item);
type List is new Abstract_Template.List with private;
type List_Item is new Abstract_Template.List_Item with private;
type List_Iterator is new Abstract_Template.List_Iterator with private;
-- now the compiler requires to implement all abstract functions
-- including the generic Iterate and Delete procedures
function Is_Empty (L : List) return Boolean;
generic
with procedure On_Item (E : in out Item);
procedure For_Each (L : in List);
...
end Concrete_Lists;
An solution without (abtract) interfaces can be obtained from
ftp.iks-jena.de:/pub/mitarb/lutz/ada/types/
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Generic abstracts
1999-11-29 0:00 ` Lutz Donnerhacke
@ 1999-11-29 0:00 ` Tucker Taft
1999-11-30 0:00 ` Lutz Donnerhacke
1999-11-30 0:00 ` Robert A Duff
0 siblings, 2 replies; 8+ messages in thread
From: Tucker Taft @ 1999-11-29 0:00 UTC (permalink / raw)
Lutz Donnerhacke wrote:
>
> * Tucker Taft wrote:
> >Lutz Donnerhacke wrote:
> >> The abstract definition should be used to ensure a consistent
> >> interface. I have two problems:
> >> - A generic procedure which can be missed on implementation.
> >> Raising an exception might be acceptable.
> >> - It is not possible to predefine a body for a generic function.
> >> No return value is available.
> >> Raising an exception does not stop the compiler from requiring
> >> a return value.
> >
> >I'm unclear as to what you are trying to accomplish by including
> >generic subprograms that are abstract. Generic subprograms are
> >not inherited, so there is no point in declaring them on an
> >abstract type.
>
> with Abstract_Lists;
>
> generic
> type Item (<>) is abstract tagged limited private;
> package Concrete_Lists is
> package Abstract_Template is
> new Abstract_Lists (Item => Item);
>
> type List is new Abstract_Template.List with private;
> type List_Item is new Abstract_Template.List_Item with private;
> type List_Iterator is new Abstract_Template.List_Iterator with private;
>
> -- now the compiler requires to implement all abstract functions
> -- including the generic Iterate and Delete procedures
So you would like a derived type to inherit the generic
subprogrmas of its parent type, and if they are abstract,
be required to implement them? This seems like a reasonable
request, but Ada has never supported inheritance of anything
but subprograms and enumerals. One could imagine inheriting other
things I suppose, such as exceptions, generics, subpackages, etc.
However, at the moment only "overloadable" things (i.e. subprograms
and enumerals) are inheritable, and that has some nice properties.
Be that as it may, I now understand what you were trying to do
and can safely answer that it is not supported by the Ada inheritance
model.
>
> function Is_Empty (L : List) return Boolean;
>
> generic
> with procedure On_Item (E : in out Item);
> procedure For_Each (L : in List);
>
> ...
> end Concrete_Lists;
>
> An solution without (abtract) interfaces can be obtained from
> ftp.iks-jena.de:/pub/mitarb/lutz/ada/types/
--
-Tucker Taft stt@averstar.com http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.) Burlington, MA USA
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Generic abstracts
1999-11-29 0:00 ` Tucker Taft
@ 1999-11-30 0:00 ` Lutz Donnerhacke
1999-11-30 0:00 ` Robert A Duff
1 sibling, 0 replies; 8+ messages in thread
From: Lutz Donnerhacke @ 1999-11-30 0:00 UTC (permalink / raw)
* Tucker Taft wrote:
>So you would like a derived type to inherit the generic
>subprogrmas of its parent type, and if they are abstract,
>be required to implement them?
Yep.
>Be that as it may, I now understand what you were trying to do
>and can safely answer that it is not supported by the Ada inheritance
>model.
Thnx. I'll spend efforts on other topics now.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Generic abstracts
1999-11-29 0:00 ` Tucker Taft
1999-11-30 0:00 ` Lutz Donnerhacke
@ 1999-11-30 0:00 ` Robert A Duff
1999-11-30 0:00 ` Tucker Taft
1 sibling, 1 reply; 8+ messages in thread
From: Robert A Duff @ 1999-11-30 0:00 UTC (permalink / raw)
Tucker Taft <stt@averstar.com> writes:
> However, at the moment only "overloadable" things (i.e. subprograms
> and enumerals) are inheritable, and that has some nice properties.
I don't see the connection between overloadable and inheritable.
By the way, I have wanted to write overloaded generic functions in the
past...
- Bob
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Generic abstracts
1999-11-30 0:00 ` Robert A Duff
@ 1999-11-30 0:00 ` Tucker Taft
0 siblings, 0 replies; 8+ messages in thread
From: Tucker Taft @ 1999-11-30 0:00 UTC (permalink / raw)
Robert A Duff wrote:
>
> Tucker Taft <stt@averstar.com> writes:
>
> > However, at the moment only "overloadable" things (i.e. subprograms
> > and enumerals) are inheritable, and that has some nice properties.
>
> I don't see the connection between overloadable and inheritable.
By restricting inheritance to overloadable things, you don't get
collisions when you have two derived types in the same scope, since
overloadables won't hide each other unless they have identical
types, which can't happen when defining a new derived type.
>
> By the way, I have wanted to write overloaded generic functions in the
> past...
I can't help you with that today ;-).
>
> - Bob
--
-Tucker Taft stt@averstar.com http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.) Burlington, MA USA
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~1999-11-30 0:00 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1999-11-25 0:00 Generic abstracts Lutz Donnerhacke
1999-11-25 0:00 ` Lutz Donnerhacke
1999-11-29 0:00 ` Tucker Taft
1999-11-29 0:00 ` Lutz Donnerhacke
1999-11-29 0:00 ` Tucker Taft
1999-11-30 0:00 ` Lutz Donnerhacke
1999-11-30 0:00 ` Robert A Duff
1999-11-30 0:00 ` Tucker Taft
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox