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 <[email protected]> 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 <[email protected]>: >> 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 <[email protected]> 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 <[email protected]>: >>>> 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 >>>> [email protected] >>>> 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 >>> [email protected] >>> https://lists.jboss.org/mailman/listinfo/rules-dev >>> >> >> _______________________________________________ >> rules-dev mailing list >> [email protected] >> 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 > [email protected] > https://lists.jboss.org/mailman/listinfo/rules-dev > _______________________________________________ rules-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/rules-dev
