Re: Generic Formal Parameter for a Task Type

[Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov>]

James Rogers <jimmaureenrogers@worldnet.att.net> writes:

> Yes, each of these is a possible way to create a system for monitoring
> and controlling a set of tasks. 
> 
> I like your idea of the abstract limited tagged type containing a
> "Task_ID" function. Unfortunately, this still adds a lot of 
> overhead when all I want to do is monitor and control the creation
> of tasks.

By "overhead" here I guess you mean "code I have to write". The
implementation of the Java task hierarchy (which you are trying to get
in Ada) must have about the same amount of run-time "overhead", since
it does the same things. It's just that Java has already done the
implementation.

This is a _feature_ of Ada, since it lets you get exactly the
structure and semantics _you_ want, rather than the particular one the
Java language implementers decided to give you. Once someone has done
it and published it, you are free to reuse that, or do something
different. Java gives you no choice.

> Note that the problem I am trying to solve does not require much
> knowledge about the task, only the ability to create an instance,
> and the ability to query a task attribute.

Java gives you more than that, but you don't complain about "overhead"
there. 

> I fully realize the problem can be solved by building an elaborate
> scaffold of data and code structure. 

Similar to the one Java gives you.

> I was hoping to achieve the results simply and cleanly. 

Look at the Java code implementing the task hierarchy; is it simple
and clean?

> I was hoping to avoid the additional overhead of code bloat
> resulting from building tagged types and associated subprograms.

Be sure you are comparing the same things.

> 
> 
> Jim Rogers Colorado Springs, Colorado USA
> 
> Tucker Taft wrote:
> > 
> > Why not have a formal function that returns the Task_ID, rather
> > than 'Terminated?  That way, you can use the Ada.Task_Identification
> > and Ada.Task_Attributes packages to get whatever else you need from the
> > task, including task attributes...
> > 
> > If you wanted to avoid generics, you could define an abstract limited
> > tagged type (say "Has_Task") which had various (abstract) primitive
> > operations, including  at least a "Task_ID" function.  You would then
> > extend from this type by adding a component of the task type of interest
> > (and of course override the abstract primitives as appropriate).
> > You could then manipulate objects of type Has_Task'Class, or references
> > there-to, in a "Java"-like way ;-).  You could also pass in any
> > extension of Has_Task to a generic with a formal tagged derived type
> > of "type My_Task is new Has_Task with private;".
> > 
> > The possibilities are endless...

-- 
-- Stephe