[jboss-jira] [JBoss JIRA] (JBRULES-3514) Add support to event sequencing

[Edson Tirelli (JIRA)]

    [ https://issues.jboss.org/browse/JBRULES-3514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12694316#comment-12694316 ] 

Edson Tirelli edited comment on JBRULES-3514 at 5/21/12 9:08 AM:
-----------------------------------------------------------------

===== FROM DAVIDE =====

Hi Edson, my quick 2 cents on this proposal

Section 2:
I like the idea of "defining" rather than just declaring datatypes and events. This problem actually overlaps much with "semantic" classes (actually semantic traits), where, in addition to declaring the type, ancestors and member fields, an "equivalentTo" LHS-like definition(s) may be provided.

So I wonder if we could merge the two parts (syntax is tentative here)

{code}declare event VoiceCallEvent extends SuperTypeEvent   // promote event to first-class ?
  into( voiceCalls )             // either keyword or annotation @into( voicecalls ) ?
  as                             // equivalent-to definitions
  callStart   : CallStartEvent() -> 
  callEnd     : CallEndEvent( callingNumber == callStart.callingNumber )
  $phone      : MobileDevice( number == callStart.callingNumber )
  $cust       : Customer( id == $phone.customerId )
  ;
  
  // fields. in DL would be considered anonymous superclasses
  callStart   : CallStartEvent           // ok: initialize when var name coincides
  callEnd     : CallEndEvent
  customer    : Customer         = $cust // should we allow explicit initialization using other expressions, possibly involving local vars ?
end{code}

Section 3 : ok

Section 4 : I'd either use infix A() -> B() or prefix notation, but I wouldn't mix the two seq( A() B() ), as we do with and/or CEs. 
Unless the parser requires so :)

Question: what about a "strict sequencing" operator A() => B(), meaning "B() after A() and nothing in between"?
Question: what about the interval deadlines, like we have in "after[a,b]" ?

Section 4 again :) :
Another options, maybe uglier? 
{code}A+( ... ), B*(....), C[2:4](...){code}

Yet another, maybe more explicit?
{code}exists[+] A(), exists[*] B(), exists[2:3] C(){code}

Section 4.1
Ok! this is again related to what I've been dreaming of writing even in more traditional DRL:     
{code}$x : exists X(){code}

Section 5.5
I'd use "not" ... what would be the high-level difference between "no" and "not" from 
a conceptual perspective? (not talking about implementation here)
Moreover, shouldn't we stick to the "not X( this after $y )" semantics we already have?

                
      was (Author: tirelli):
    ===== FROM DAVIDE =====

Hi Edson, my quick 2 cents on this proposal

Section 2:
I like the idea of "defining" rather than just declaring datatypes and events. This problem actually overlaps much with "semantic" classes (actually semantic traits), where, in addition to declaring the type, ancestors and member fields, an "equivalentTo" LHS-like definition(s) may be provided.

So I wonder if we could merge the two parts (syntax is tentative here)

declare event VoiceCallEvent extends SuperTypeEvent   // promote event to first-class ?
  into( voiceCalls )             // either keyword or annotation @into( voicecalls ) ?
  as                             // equivalent-to definitions
  callStart   : CallStartEvent() -> 
  callEnd     : CallEndEvent( callingNumber == callStart.callingNumber )
  $phone      : MobileDevice( number == callStart.callingNumber )
  $cust       : Customer( id == $phone.customerId )
  ;
  
  // fields. in DL would be considered anonymous superclasses
  callStart   : CallStartEvent           // ok: initialize when var name coincides
  callEnd     : CallEndEvent
  customer    : Customer         = $cust // should we allow explicit initialization using other expressions, possibly involving local vars ?
end

Section 3 : ok

Section 4 : I'd either use infix A() -> B() or prefix notation, but I wouldn't mix the two seq( A() B() ), as we do with and/or CEs. 
Unless the parser requires so :)

Question: what about a "strict sequencing" operator A() => B(), meaning "B() after A() and nothing in between"?
Question: what about the interval deadlines, like we have in "after[a,b]" ?

Section 4 again :) :
Another options, maybe uglier? 
A+( ... ), B*(....), C[2:4](...)

Yet another, maybe more explicit?
exists[+] A(), exists[*] B(), exists[2:3] C()

Section 4.1
Ok! this is again related to what I've been dreaming of writing even in more traditional DRL:     
$x : exists X()

Section 5.5
I'd use "not" ... what would be the high-level difference between "no" and "not" from 
a conceptual perspective? (not talking about implementation here)
Moreover, shouldn't we stick to the "not X( this after $y )" semantics we already have?

                  
> Add support to event sequencing
> -------------------------------
>
>                 Key: JBRULES-3514
>                 URL: https://issues.jboss.org/browse/JBRULES-3514
>             Project: Drools
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: drools-api, drools-compiler, drools-core
>            Reporter: Edson Tirelli
>            Assignee: Edson Tirelli
>             Fix For: 5.5.0.Beta1
>
>
> The purpose of this ticket is to centralize the discussions regarding the implementation of event sequencing as detailed in the wiki page at:
> https://community.jboss.org/wiki/EventSequencing
> The highlevel discussions can be added to this ticket while individual sub-tickets will be created for the implementation of each sub-feature.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira