RE: [rules-dev] Determining if a class is an event or not

Hi Felipe, I recall Edson saying that "Event" classes need to be ascertained at (RETE) compilation time - which, I think, rules out the API addition. I was hoping Edson, time permitting, would explain how declarative (fact-centric class) imports currently work to generate an ObjectTypeNode and therefore to understand how his proposal to create cached ObjectTypeConf instances for Event-centric classes compares. My reasoning being that if the process is similar the new event stuff should be no different; simply having two ObjectTypeNodes - one for Events and another for Facts. See attached. It's quite possible our exchanges have given Edson time to come to his own conclusion and the solution is now being coded! With kind regards, Mike _____ From: rules-dev-bounces(a)lists.jboss.org [mailto:rules-dev-bounces@lists.jboss.org] On Behalf Of Felipe Piccolini Sent: 12 November 2007 13:25 To: Rules Dev List Subject: Re: [rules-dev] Determining if a class is an event or not Well, IMHO for the experience I have I suggest to implement both solutions: -an API insertEvet() so the user can implement the mechanism to manage their rules knowing when a fact is an event or not. -an Interface Event so when the user cant manage the flow asserting facts, when he cant know when a fact is or not an event, then maybe he can wrap some facts on this interface and the API insert() internaly can check if the fact is an event or not and call insertEvent if necesary. :) On 08-11-2007, at 11:27, Anstis, Michael ((M.)) wrote: Here's my 2 cents - as a non-contributor to Drools codebase ;-) You could add insertEventFactTypeThingie to the API? Then you need just check that the class has been declared as an event in the DRL similar to what must already happen for normal DRL imports. I personally don't have issue with implementing a marker interface (this is what frameworks like Hibernate, EJB3 and Spring etc have been imposing for years). What "wiring" does the POJO need to become an Event for use in Drools? Are you trying to internalise too much at the risk of making the event mechanism inflexible? Cheers, Mike -----Original Message----- From: rules-dev-bounces(a)lists.jboss.org [mailto:rules-dev-bounces@lists.jboss.org] On Behalf Of Matthias Sent: 08 November 2007 13:09 To: rules-dev(a)lists.jboss.org Subject: Re: [rules-dev] Determining if a class is an event or not Edson Tirelli <tirelli <at> post.com> writes: All, I reached a point where I need to make a design decision and would like your opinion about it. Imagine the following scenario: A user has a domain model like this:package a.b.c ;public interface Event { ... }package x.y.z;public class MyEvent implements a.b.c.Event {...} Then, in his DRL file he writes:package p.q.r;import event a.b.c.*; rule Xwhen Event( ... )then ...end So, it is clear that a.b.c.Event should be handled as an event by the engine. At runtime, the user asserts an object of the class x.y.z.MyEvent into the working memory. Seems clear to me (and probably to the user) that MyEvent should be handled as an event, since by DRL semantics, a.b.c.* are all events, and by OO class hierarchy concept, since a.b.c.Event is an event, x.y.z.MyEvent is an event too. My question is: how the engine knows that MyEvent is an event, since it only has the x.y.z.MyEvent class as input? The only answer I have is that when the first MyEvent instance is asserted into the working memory, we must get the class name and iterate over all event import declarations checking for a match. In case no one is found, we need to repeat the process for each interface and each class up in the MyEvent hierarchy. Once this process is complete, we cache the results in the ObjectTypeConf. This may be a quite heavy process to be executed each time a fact of a different class is asserted in the working memory for the first time, but I can't think a different user-friendly way to solve the question. The alternatives would be intrusive, IMO, breaking the drools premise to work with user-defined POJOs as facts: use anotations to annotate classes that are events, or mandate users implement a specific interface for events. Any better idea? []s Edson -- Edson Tirelli Software Engineer - JBoss Rules Core Developer Office: +55 11 3529-6000 Mobile: +55 11 9287-5646 JBoss, a division of Red Hat <at> www.jboss.com _______________________________________________ rules-dev mailing list rules-dev <at> lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev Edson, I got your striving not to mandate users implement a specific interface for events. However, why not at least introducing an empty event interface (i.e. a marker interface, similar to the Serializable interface in Java) the user-defined event class(es) have to implement? This way, when inserting a MyEvent instance, you can simply check whether it implements the event interface (by means of 'instanceof'). Moreover, while parsing the import statements of a rule file, it enables you to double-check whether all the "event imports" really refer to classes implementing the (empty) event interface. In this regard, for me another question raises: Without making any restrictions on the structure for a user defined event class, how do you make sure it has all the required attributes of an event (which in my opinion must be a timestamp, at least) and how do you access them (necessary for temporal relationships)? Having said this, in my opinion defining an empty event interface may not be sufficient; in addition, it must force the user to implement a method returning the event's occurrence date (i.e. the timestamp) at least... Or how would you handle this issue? Matthias _______________________________________________ rules-dev mailing list rules-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev _______________________________________________ rules-dev mailing list rules-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev Felipe Piccolini M. <mailto:felipe.piccolini@bluesoft.cl> felipe.piccolini(a)bluesoft.cl