Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (athena.apache.org: domain of ole.ersoy@gmail.com
 designates 209.85.220.171 as permitted sender)
Message-ID: <4E4147BF.6050608@gmail.com>
Date: Tue, 09 Aug 2011 09:44:15 -0500
From: Ole Ersoy <ole.ersoy@gmail.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
 rv:1.9.1.12) Gecko/20100907 Fedora/3.0.7-1.fc12 Thunderbird/3.0.7
MIME-Version: 1.0
To: Commons Developers List <dev@commons.apache.org>
Subject: Re: [math] Monitoring iterative algorithms
References: 
 <CAGRH7HrgcgoBA=jcoKovjiQU=TjpQHnspBkOGNCu7oDdKk=K4w@mail.gmail.com>
	<4E4049F2.3040109@gmail.com>
 <CAGRH7HpxeW8GkLkWRKnfTj8kL64E_2waJB0THuPvQbRT-PQELQ@mail.gmail.com>
In-Reply-To: 
 <CAGRH7HpxeW8GkLkWRKnfTj8kL64E_2waJB0THuPvQbRT-PQELQ@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

One approach that will minimize the burden on commons math developers is to point users to an AspectJ approach as is discussed here:

http://www.ibm.com/developerworks/java/library/j-aopwork6/index.html

The article starts out with a discussion of how to implement the observer design pattern the classic way, along with the associated design and maintenance costs, and then explains how to do it with AspectJ which leaves the class of the objects being observed in its original form.

Cheers,
- Ole


On 08/09/2011 12:46 AM, S�bastien Brisard wrote:
> 2011/8/8 Phil Steitz<phil.steitz@gmail.com>:
>>
>> +1 to the idea of using the Observer pattern; but -0 for
>> Observable.  I would favor defining Events and Listeners because a)
>> Observable is concrete, so effectively forces you to create an
>> Observable delegate
>>
> I'm not sure I understand. Components in java.awt also need to
> implement quite a few methods like addListener, fireEvent, and so on.
> Maybe we could write a DefaultObservable, which would implement most
> of the methods required by Observable, and could be inherited by some
> (probably not all, unfortunately) of the already implemented iterative
> algorithms ?
>>
>> and b) the interface is crude and is really
>> designed for GUI scenarios where observers are holding references to
>> the Observable and just being notified that something has changed.
>> Events are more flexible and can be implemented using interfaces.
>> Has anyone ever actually used Observable outside of a GUI m/v
>> environment?   Does anyone know of event frameworks suitable for
>> monitoring long-running computations that we might adapt?
>>
>> In any case, I think it is a good idea to develop an event framework
>> for [math].  We should probably also think about doing this in a way
>> that is at least JMX-friendly.
>>
>> Phil
>>
> Browsing through the JavaDoc, I realized that o.a.c.m.ode has some
> event handling facilities. Is the implementer still around?
> Sebastien
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org