For what it's worth I like the thought of:- $p : Person() Cheese ( name == $p.favouriteCheese )
I like even more:- $p : Person() Cheese ( name == $p.favouriteFoods.favouriteCheese ) <-- i.e. object model navigation And possibly (subject to constrains such as "must be a Map" - I think there's a similar requirement for extension of "contains"):- $p : Person() Cheese ( name == $p.favouriteFoods["cheese"] ) I'm with Edson (given my limited use) regarding pattern matches - it's easier for me (as a user) to understand. I can't say I understand what the cross-product issue is though (I know "cross-product==bad"). Cheers, Mike -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Edson Tirelli Sent: 20 March 2007 23:22 To: Rules Dev List Subject: Re: [rules-dev] sugar Yes, that is the part that I agreed.... :) I just would NOT want: Cheese( name == Person().favouriteCheese ) []s Edson Michael Neale wrote: > I am not sure about the "danger", but I do like anything that avoids > extra binding. > So lets not throw the baby out with the bathwater. > > I really like: > $p : Person() > Cheese( name == $p.favouriteCheese ) > > I think that should definately be allowed. > > > On 3/21/07, *Edson Tirelli* <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > > 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: [EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> > >[mailto:[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>] 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 > >>[email protected] <mailto:[email protected]> > >>https://lists.jboss.org/mailman/listinfo/rules-dev > >> > >> > >> > > > >_______________________________________________ > >rules-dev mailing list > >[email protected] <mailto:[email protected]> > > https://lists.jboss.org/mailman/listinfo/rules-dev > >_______________________________________________ > >rules-dev mailing list > >[email protected] <mailto:[email protected]> > >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 <http://www.jboss.com> > > > _______________________________________________ > rules-dev mailing list > [email protected] <mailto:[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 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 _______________________________________________ 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
