comp.lang.ada
 help / color / mirror / Atom feed
* Q. about Inheritance in Ada95
@ 1996-07-02  0:00 Wajdi H Al-Jedaibi (INFT)
  1996-07-02  0:00 ` Robert A Duff
                   ` (2 more replies)
  0 siblings, 3 replies; 6+ messages in thread
From: Wajdi H Al-Jedaibi (INFT) @ 1996-07-02  0:00 UTC (permalink / raw)



Here is the question:
	Does Ada 95 allows for task to be extended. It seems that this point
	is not clearly addressed in the ref manual. If it does not, is there
        a way to to incorporate inheritance for ada tasks?

Thanks 
--
Wajdi.




^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Q. about Inheritance in Ada95
  1996-07-02  0:00 Q. about Inheritance in Ada95 Wajdi H Al-Jedaibi (INFT)
@ 1996-07-02  0:00 ` Robert A Duff
  1996-07-03  0:00   ` Mark A Biggar
  1996-07-03  0:00 ` Jon S Anthony
  1996-07-03  0:00 ` Tucker Taft
  2 siblings, 1 reply; 6+ messages in thread
From: Robert A Duff @ 1996-07-02  0:00 UTC (permalink / raw)



In article <4rc2q8$b84@portal.gmu.edu>,
Wajdi H Al-Jedaibi (INFT) <waljedai@site.gmu.edu> wrote:
>	Does Ada 95 allows for task to be extended.

Not directly.  However, you can do things like this:

    type Action is access procedure;

    task type Do_Anything(To_Do: Action);

    task body Do_Anything is
    begin
        To_Do.all;
    end Do_Anything;

Now you can create tasks to do whatever you like:

    procedure My_Action is ...
    
    Task_Obj: Do_Anything(To_Do => My_Action'Access);

- Bob




^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Q. about Inheritance in Ada95
  1996-07-03  0:00   ` Mark A Biggar
@ 1996-07-03  0:00     ` Robert A Duff
  0 siblings, 0 replies; 6+ messages in thread
From: Robert A Duff @ 1996-07-03  0:00 UTC (permalink / raw)



In article <4re31p$19@wdl1.wdl.loral.com>,
Mark A Biggar <mab@dst17.wdl.loral.com> wrote:
>Well anything except talk to other such tasks, such a task can't accept any
>entry calls as it can't legaly contain any accept statements.

True.

Such a task would talk to other tasks via protected objects.  No need
for accept statements.

- Bob




^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Q. about Inheritance in Ada95
  1996-07-02  0:00 Q. about Inheritance in Ada95 Wajdi H Al-Jedaibi (INFT)
  1996-07-02  0:00 ` Robert A Duff
@ 1996-07-03  0:00 ` Jon S Anthony
  1996-07-03  0:00 ` Tucker Taft
  2 siblings, 0 replies; 6+ messages in thread
From: Jon S Anthony @ 1996-07-03  0:00 UTC (permalink / raw)



In article <4rc2q8$b84@portal.gmu.edu> waljedai@site.gmu.edu (Wajdi H Al-Jedaibi (INFT)) writes:

> Here is the question:
> 	Does Ada 95 allows for task to be extended. It seems that this point

No.  Only tagged types may be extended.  Well, unless you're talking about
behavior in which case most types can be (just like in Ada83), but still
not task types (or protected types).


> If it does not, is there a way to to incorporate inheritance for ada
>  tasks?

Kinda, sorta, maybe, depending on.  What you can do is define a tagged
type which contains a task type.  You can then extend the tagged type.
If you don't need to modify the tasking aspect, you can just add more
attributes and/or operations.  If you want/need to extend the thread
capability, you have to play some games by defining a new task type for
the extension and then including this as an attribute in the extension.

In both cases, what you do is hide the tasks interface behind explicit
operations on the "containing" type.  In the cases we are talking about
here, these will also (more than likely) be primitive operations capable
of being dispatched to in the standard way.  The implementations of the
operations will call entries in the task interface of the contained task
object of the object for which the dispatch occured.

In the above scenario, you have what might be termed "active objects".
Each instance of the tagged type will end up containing one or more
threads of action.


Another way of going about it is flip all aournd and treat the task
type as the "major" type and parameterize it with access to classwide
types representing the extendable types in which you are interested.
Then in the bodies of the entries defined by the task type, you
actually dispatch on the primitive operations "representing" them in
the definitions of the various type extensions in the given classes.

In this case you are directly interfacing with and accessing the task
objects which just happen to have the ability to deal with
hetergeneous collections of objects (the instances of the derivation
trees subsumed by the class parameter(s)).


Here's a silly example I hacked up (oops, four letter word here!)
concerning the former technique about a year or so ago.  Hmmm, looking
this over I see that it also includes (in the implementation) examples
of the latter technique as well...

----------------------------

First, we create a "base" active object thing (with some pretty
contrived operations...):


package Active_Objs is

    type Obj_Type ( Name : access String ) is tagged limited private;

    procedure Op1 ( Obj : Obj_Type );

    function Name ( Obj : Obj_Type ) return String;

private

    task type Action_Type ( Obj : access Obj_Type'Class ) is
	entry Op1;
	entry Name ( N : out String );
    end Action_Type;

    type Obj_Type ( Name : access String ) is tagged limited record
	Actions : Action_Type(Obj_Type'Access);
    end record;

end Active_Objs;


package body Active_Objs is

    task body Action_Type
    is
    begin	
	accept Op1 do
	    null; -- op1 stuff...
	end Op1;

	accept Name ( N : out String ) do
	    N := Obj.Name.all;
	end Name;
    end Action_Type;


    procedure Op1 ( Obj : Obj_Type )
    is
    begin -- Op1
	Obj.Actions.Op1;
    end Op1;
    

    function Name ( Obj : Obj_Type ) return String
    is
	Result : String(1..Obj.Name'Length);
    begin -- Name
	Obj.Actions.Name(Result);
	return Result;
    end Name;
    
end Active_Objs;


OK, anything in Active_Objs.Obj_Type'Class will have at least one independent
thread of action -- that given by Actions_Type.  So, we can now extend this
with some new functionality which we assume needs more independent actions.


with Active_Objs;
package My_Active is

    type Obj_Type is new Active_Objs.Obj_Type with private;

    procedure Op2 ( Obj : Obj_Type );
    function  Id  ( Obj : Obj_Type ) return Integer;

private

    task type My_Actions_Type ( Obj : access Obj_Type'Class ) is
	entry Op2;
	entry Id ( I : out Integer );
    end My_Actions_Type;

    type Obj_Type is new Active_Objs.Obj_Type with record
	My_Actions : My_Actions_Type(Obj_Type'Access);
	Id : Integer := 0;  -- Holds the instances Object ID...
    end record;

end My_Active;


package body My_Active is

    -- Make generation of new OIDs task safe!
    --
    protected Oids is
	procedure New_Id ( I : out Integer );
    private
	Num : Integer := 0;
    end Oids;

    protected body Oids is
	procedure New_Id ( I : out Integer ) is
	begin
	    Num := Num + 1;  -- This update is guaranteed mutually exclusive!
	    I := Num;
	end New_Id;
    end Oids;


    task body My_Actions_Type
    is
    begin	
	accept Op2 do
	    null; -- op1 stuff...
	end Op2;

	accept Id ( I : out Integer ) do
	    if Obj.Id = 0 then
		Oids.New_Id(Obj.Id);  -- Safely get a _unique_ ID
	    end if;
	    I := Obj.Id;
	end Id;
    end My_Actions_Type;


    procedure Op2 ( Obj : Obj_Type )
    is
    begin -- Op2
	Obj.My_Actions.Op2;
    end Op2;
    
    function  Id  ( Obj : Obj_Type ) return Integer
    is
	Result : Integer;
    begin -- Id
	Obj.My_Actions.Id(Result);
	return Result;
    end Id;
    

end My_Active;


Now, anything in My_Active.Obj_Type'Class will have at least _two_
independent threads of action.  Certainly we are not _required_ to
extend with extra threads of action, but if the actions we extend with
are somehow required to be task safe, say, then this is an appropriate
thing to do.  Or, if the actions really are independent (say pistons
moving affecting wheels turning or propellor turning) then this makes
excellent sense.

Now, as I say, the example here is really pretty lame, but just to finish it
off, here is a use of the above:

with My_Active;
with Text_Io;  use Text_Io;
procedure Active is

    -- Since Obj is in My_Actions.Obj_Type'Class, it has both threads of
    -- action: the one from the base Active_Objs.Obj_Type and the one from
    -- the extension My_Active.Obj_Type...
    --
    Obj : My_Active.Obj_Type (new String'("Mary"));

begin
    My_Active.Op1(Obj);
    My_Active.Op2(Obj);
    Put_Line("My name is " & My_Active.Name(Obj));
    Put_Line("My ID is " & Integer'Image(My_Active.Id(Obj)));
end Active;

$ gnatmake active.adb
$ active
My name is Mary
My ID is  0
$


/Jon

-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com





^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Q. about Inheritance in Ada95
  1996-07-02  0:00 Q. about Inheritance in Ada95 Wajdi H Al-Jedaibi (INFT)
  1996-07-02  0:00 ` Robert A Duff
  1996-07-03  0:00 ` Jon S Anthony
@ 1996-07-03  0:00 ` Tucker Taft
  2 siblings, 0 replies; 6+ messages in thread
From: Tucker Taft @ 1996-07-03  0:00 UTC (permalink / raw)



Wajdi H Al-Jedaibi (INFT) (waljedai@site.gmu.edu) wrote:
: Here is the question:
: 	Does Ada 95 allows for task to be extended. It seems that this point
: 	is not clearly addressed in the ref manual. 

No, only tagged types support type extension.

:       If it does not, is there
:         a way to to incorporate inheritance for ada tasks?

You can use inheritance with Ada tasks.  Some of this is covered
in the excellent Burns & Welling book on Concurrency in Ada.
One way is to add an access discriminant to the task type, such as:

   task type TT(Queue : access Queue_Type'Class) is ...

and then make dispatching calls on "Queue" inside the body of TT.
The tagged type Queue_Type can be extended and its operations overridden
to change the internal behavior of instances of TT.

: Thanks 
: --
: Wajdi.

-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Cambridge, MA  USA




^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Q. about Inheritance in Ada95
  1996-07-02  0:00 ` Robert A Duff
@ 1996-07-03  0:00   ` Mark A Biggar
  1996-07-03  0:00     ` Robert A Duff
  0 siblings, 1 reply; 6+ messages in thread
From: Mark A Biggar @ 1996-07-03  0:00 UTC (permalink / raw)



In article <DtxuF5.BKp@world.std.com> bobduff@world.std.com (Robert A Duff) writes:
>In article <4rc2q8$b84@portal.gmu.edu>,
>Wajdi H Al-Jedaibi (INFT) <waljedai@site.gmu.edu> wrote:
>>	Does Ada 95 allows for task to be extended.
>Not directly.  However, you can do things like this:
>    type Action is access procedure;
>    task type Do_Anything(To_Do: Action);
>    task body Do_Anything is
>    begin
>        To_Do.all;
>    end Do_Anything;
>Now you can create tasks to do whatever you like:
>    procedure My_Action is ...
>    Task_Obj: Do_Anything(To_Do => My_Action'Access);

Well anything except talk to other such tasks, such a task can't accept any
entry calls as it can't legaly contain any accept statements.

--
Mark Biggar
mab@wdl.lmco.com






^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~1996-07-03  0:00 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1996-07-02  0:00 Q. about Inheritance in Ada95 Wajdi H Al-Jedaibi (INFT)
1996-07-02  0:00 ` Robert A Duff
1996-07-03  0:00   ` Mark A Biggar
1996-07-03  0:00     ` Robert A Duff
1996-07-03  0:00 ` Jon S Anthony
1996-07-03  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