[rules-dev] declare LocalEvent @role( event ) end

Wolfgang Laun wolfgang.laun at gmail.com
Wed Nov 10 12:05:52 EST 2010


Well, I think that the current situation is more useful due to its
error checking
potential than any change, and it's useless to cry over spilt milk. But I did
create another JIRA, urging several documentation fixes.

Cheers
-W

On 10 November 2010 17:12, Edson Tirelli <tirelli at post.com> wrote:
>    Wolfgang,
>
>    I am not sure how useful such a no-field control fact is, but
> anyway, feel free to open a JIRA and propose a way to support that
> from a syntax perspective. I.e., we will probably need to use a new
> annotation to allow users to explicitly tell the engine to generate
> the no-field bean, what could be more cumbersome than simply use a
> dummy field in these specific cases.
>
>    Open for suggestions,
>    Edson
>
>
> 2010/11/10 Wolfgang Laun <wolfgang.laun at gmail.com>:
>> I can declare a useful event type which doesn't have any fields
>> except the implicit timestamp and duration. As you've described,
>> the compiler assumes that this is an extension of an imported
>> fact, and complains if this cannot be found.
>>
>> Here is a complete, not too contrived use case.
>>
>> declare Trigger
>>  @role( event )
>>  @expires( 1s )
>>  void: Void         ## required due to compiler's insistence of
>> Trigger being defined elsewhere
>> end
>>
>> rule "1m ticker"
>>    timer(int: 1m 1m)
>> when
>> then
>>    insert( new Trigger() );
>> end
>>
>> rule "count jobs 30 minutes before Trigger"
>> when
>>    $t: Trigger()
>>    Number( $i: intValue > 3 ) from accumulate(
>>       Job( this before[0,30m] $t )
>>       count( 1 ) )
>> then
>>    retract( $t );
>>    System.out.println( "Too many jobs (" + $i + ") at " + clockAsString() );
>> end
>>
>> Cheers
>> Wolfgang
>>
>> On 10 November 2010 16:03, Edson Tirelli <tirelli at post.com> wrote:
>>>   Hi Wolfgang,
>>>
>>>   Not sure what is the intent with that?
>>>
>>>   Just to explain the design, the compiler differentiates two use
>>> cases: (1) if a declare has no fields in it, it understands the user
>>> is annotating an existing class. (2) If a declare has at least one
>>> field, then the compiler tries to generate a new class and annotate
>>> it.
>>>
>>>   In case (1) above, if the compiler does not find an existing class,
>>> it (correctly, IMO) raises an error.
>>>
>>>   Can you please clarify?
>>>
>>>   Thanks,
>>>       Edson
>>>
>>> 2010/11/10 Wolfgang Laun <wolfgang.laun at gmail.com>:
>>>> This simple declare for a new (not imported) class isn't permitted by
>>>> the compiler, although it makes sense.
>>>>
>>>> Of course, it's possible to work around by adding a dummy field.
>>>>
>>>> But is this restriction intentional by design, to alert users when
>>>> they misspell a class name, or forget to import a class?
>>>>
>>>> If not, I'll make a request to permit this.
>>>>
>>>> -W
>>>> _______________________________________________
>>>> rules-dev mailing list
>>>> rules-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>>>
>>>
>>>
>>>
>>> --
>>>   Edson Tirelli
>>>   JBoss Drools Core Development
>>>   JBoss by Red Hat @ www.jboss.com
>>>
>>> _______________________________________________
>>> rules-dev mailing list
>>> rules-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>>
>>
>> _______________________________________________
>> rules-dev mailing list
>> rules-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>
>
>
>
> --
>   Edson Tirelli
>   JBoss Drools Core Development
>   JBoss by Red Hat @ www.jboss.com
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>



More information about the rules-dev mailing list