Re: Announcing new interface for adding observers to a task.

[Andrew Cagney <cagney at redhat dot com>]

Hi Nurdin,

I'm having trouble following this.  Is what you're _proposing_ is as 
follows?  Given:

class Foo
 implements TaskObserver.Instruction, TaskObserver.Syscall
{
 <does stuff>
}
foo = new Foo ();

then instead of:

  task.requestAddInstructionObserver (foo);
  ,... and then later ...
  task.requestAddSyscallObserver (foo);

then the message:

  task.requestAddObserver (foo);

will automatically and immediately add both?

The current interface was chosen because it was very explicit, and 
easier to control, and besides it avoided instanceOf (which tends to 
suggest a need for polymorphism).  Your alternative may be better, 
however, I'm very itnerested in first hearing from some more hard-core 
Java developers as to what is preferred here.

Can you create a branch, and commit your change there?  That way there's 
no immediate pressure to get the change in while ensuring that it isn't 
lost.

Andrew

Nurdin Premji wrote:
> I have condensed all the observables in Task to a single observable with
> methods inside of TaskObservable to get iterators and counts of
> observers of a specific type.
>
> The way this was implemented was inside the TaskObservable class.
> Previously this was a simple extension to the observable class, but now
> it has been expanded to have methods: 
> iterator(Class) and 
> numberOfObservers(Class). 
> The iterator() method creates an iterator that goes through the
> observables set of observers returning any observer that implements the
> given class using the dynamic class method Class.isInstance(Object o).
> The numberOfObservers() method uses iterator() and a counter to find how
> many observers implement that class.
>
> This means that adding an observer should be done with the
> task.requestAddTaskObserver() method rather than what were previously
> requestAddAttachedObserver, requestAddTerminatingObserver etc.
>
> requestAddCodeObserver, requestAddSyscallObserver and
> requestAddInstructionObserver have been kept as they pass some arguments
> that are a little different than the standard add.
>
> This also means a little bit of behaviour has changed. Once you add an
> observer to a task, it is added as all of its interfaces, not just as
> the interface specified (since now we don't specify the interface.)
>
> A few test cases used the attachedObserver interface in order to cause
> certain behaviour, like having the addedTo method called multiple times.
> This will no longer work and a second observer has been created in those
> test cases. To get the same behaviour a sub class was created that
> implements the TaskObserver.Attached and that is added and deleted on
> demand rather than the major class. (The major class no longer has to
> inherit the Attached interface).
>
>
>