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

[Matthias]

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