Re: [rules-dev] sugar
I think it is a dangerous move.
It is easy for users to understand that each pattern matches a fact:
A( ... )
B( ... )
C( ... )
If you start moving patterns to inside other patterns, you risk to
lose the legibility:
A( b == B( ... ), c == C(...) )
Main problem I see is with cross product abuses:
A( oneb == B(...), thesameb == B(...) )
The above may match the same B as intended, but may also match other
Bs, leading to errors and bugs that will be hard to track.
I would continue making patterns explicit and not nested.
Although, the object navigability is desired and much waited I think:
$b : B(...)
A( c == $b.c )
Also, there are some cases that we would do good allowing nesting:
$c : Cheesery( ... )
$s : List( size < 3 ) from collect( Cheese( type == "stilton" ) from
$c.getCheeses() )
Just my .02 c.
[]s
Edson
Olenin, Vladimir (MOH) wrote:
Don't have any antlr experience, but I'd say that would be a
very valuable
addition - probably more BAs would be able to pick it up this way (without
having to fallback on custom DSL)
Vlad
-----Original Message-----
From: rules-dev-bounces(a)lists.jboss.org
[mailto:rules-dev-bounces@lists.jboss.org] On Behalf Of Mark Proctor
Sent: 20 March 2007 15:54
To: Rules Dev List
Subject: Re: [rules-dev] sugar
Could also allow:
Cheese( name = Person( location == "london").favourCheese )
Can also use this to constrain on the fact itself, instead of just a field:
Person( cheese = Cheese( type == "stilton ) )
This could be use in config options:
Call( duration < CallConf().minDuration )
But as Edson pointed out it is open to abuse and misunderstanding, how
long till people do:
Call( duration < CallConf().maxDuration, duration > CallConf().maxDuration )
Which is more like doing the following which has cross product issues:
CallConf( $maxDuration1 : maxDuration )
CallConf( $maxDuration2 : maxDuration )
Call( duration < ,$maxDuration1 duration > $maxDuration2 )
Mark
Mark Proctor wrote:
>I've been thinking of an idea to make rules more expressive, its just
>syntax sugar at the parser level, but thought i'd ask feedback - if
>anyone with antlr skills wants to make this work, let us know :)
>
>Instead of doing:
>$p : Person($favouriteCheese : favouriteCheese )
>Cheese( name == $favouriteCheese )
>
>We should allow the following:
>$p : Person()
>Cheese( name == $p.favouriteCheese )
>
>We could take this further and in places where a pattern is not used
>elsewhere allow:
>Cheese( name == Person().favouriteCheese )
>
>Mark
>
>
>
>_______________________________________________
>rules-dev mailing list
>rules-dev(a)lists.jboss.org
>https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
>
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
--
Edson Tirelli
Software Engineer - JBoss Rules Core Developer
Office: +55 11 3124-6000
Mobile: +55 11 9218-4151
JBoss, a division of Red Hat @ www.jboss.com