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

[ https://issues.jboss.org/browse/JBRULES-3514?page=com.atlassian.jira.plug... ] 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? -- 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