Cheese ( name == $p.favouriteFoods.favouriteCheese )	
That is a different thing, because a rule engine can only understand the asserted facts and their direct properties, so where as one is a short cut for a standard variable constraint, the other in the expression above, would have to be swapped out for a return value constraint with the expression executed by MVEL. That is also planned. However be aware that excessive use of deep nested graphs will really just turn drools into a standard scripting engine.

Mark

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: rules-dev-bounces@lists.jboss.org
[mailto:rules-dev-bounces@lists.jboss.org] 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* <tirelli@post.com 
<mailto:tirelli@post.com>> 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: rules-dev-bounces@lists.jboss.org
    <mailto:rules-dev-bounces@lists.jboss.org>
    >[mailto:rules-dev-bounces@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@lists.jboss.org <mailto:rules-dev@lists.jboss.org>
    >>https://lists.jboss.org/mailman/listinfo/rules-dev
    >>
    >>
    >>
    >
    >_______________________________________________
    >rules-dev mailing list
    >rules-dev@lists.jboss.org <mailto:rules-dev@lists.jboss.org>
    > https://lists.jboss.org/mailman/listinfo/rules-dev
    >_______________________________________________
    >rules-dev mailing list
    >rules-dev@lists.jboss.org <mailto:rules-dev@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
    

<http://www.jboss.com>
  

    _______________________________________________
    rules-dev mailing list
    rules-dev@lists.jboss.org <mailto:rules-dev@lists.jboss.org>
    https://lists.jboss.org/mailman/listinfo/rules-dev


-----------------------------------------------------------------------
    

-
  

_______________________________________________
rules-dev mailing list
rules-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev