Re: [rules-users] Condition syntax to access Map
2011/7/31 Mark Proctor mproc...@codehaus.org On 31/07/2011 19:39, Wolfgang Laun wrote: 2011/7/31 Mark Proctor mproc...@codehaus.org Implicit mapping I call Managed Object Graphs MOGs. So you can write Person( address.street == my road ) And that internally would get translated too $p : Person() Address( person == $p, street == my road ) As there is no doubt that the current explicit bindings approach on objects is too verbose and hard to read. Nested accessors add a lot of readability. So what if Address is not an inserted fact? So far, a CE with type Foo(...) implied the existence of a fact of that type. I'm not sure that inserting some object should imply the insertion of all of its descendants as facts as well... You don't necessarily have to insert Address. It can attach a listener, assuming the pojo supported it, when it's accessed in a pattern - allowing the pattern to receive updates from nested objects. Surely you mean that changes to Address should result in an update notification for the owning Person object. - But that's not what I meant. The LHS Person(...) alone fires due a Person inserted and not when an Address is inserted; it fires again if a Person() update is signalled. In contrast, Person() Address(...) fires after both have been inserted and again after *either one* has been updated. Something can't be inserted anyway unless it has the necessary references for the joins. This references I doubt very much. Surely you can insert anything. And joins are possible on (primary key attributes as well. I want to look at a full range of MOGs to automate and semi-autimate things with regards to nested structures. At the moment there is no best practice and DRL (or any other rule language) does not make this nice. We ALL suck for compact nested accessors. The notation a.b.c reflects an implementation technique for a hierarchical data type. (Traditionally, x-dot-y means add the offset for y to the address resulting from x.) A more general concept for navigation in a data structure would have to separate a logical relationship from the implementation technique. It may be necessary to retain the dot notation for the hard coded access and to devise an entirely new notation for logical navigation. As a somewhat contrived example, assume that Address is stored as a map field with key addr and the street is the second text line of the address: declare Person name : String # default implementation as JBean field props : Map address : Address as props[addr] # the implementation end declare Address lines : String[] street : String as lines[1] end Person( name == Psmith, address/street == Main Drag ) Car( owner/address/street ... ) # Person owner Notice that explicitly using props[addr] or lines[1] is just another implementation dependent notation which breaks as soon as someone decides to change it in the class. Such things should not permeate application code. Also, notice that a navigation expression could be dynamic, making navigation dependent on the object's state, or whatever. -W Mark -W ___ rules-users mailing listrules-users@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-users ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Condition syntax to access Map
On 02/08/2011 07:15, Wolfgang Laun wrote: 2011/7/31 Mark Proctor mproc...@codehaus.org mailto:mproc...@codehaus.org On 31/07/2011 19:39, Wolfgang Laun wrote: 2011/7/31 Mark Proctor mproc...@codehaus.org mailto:mproc...@codehaus.org Implicit mapping I call Managed Object Graphs MOGs. So you can write Person( address.street == my road ) And that internally would get translated too $p : Person() Address( person == $p, street == my road ) As there is no doubt that the current explicit bindings approach on objects is too verbose and hard to read. Nested accessors add a lot of readability. So what if Address is not an inserted fact? So far, a CE with type Foo(...) implied the existence of a fact of that type. I'm not sure that inserting some object should imply the insertion of all of its descendants as facts as well... You don't necessarily have to insert Address. It can attach a listener, assuming the pojo supported it, when it's accessed in a pattern - allowing the pattern to receive updates from nested objects. Surely you mean that changes to Address should result in an update notification for the owning Person object. - But that's not what I meant. When the expression is evaluated we could detect that Address is not inserted and attach a listener to that specific instance, so we can receive updates for it. So for that rule it would work the same as Person() Address() yet Address was never inserted. Note that it would be a lightweight listener just for that join, and not a global insertion. It could be possible to global insert something too on demand, but we'd need something annotation driven to allow the user to specify their intent. The LHS Person(...) alone fires due a Person inserted and not when an Address is inserted; it fires again if a Person() update is signalled. In contrast, Person() Address(...) fires after both have been inserted and again after /either one/ has been updated. Something can't be inserted anyway unless it has the necessary references for the joins. This references I doubt very much. Surely you can insert anything. And joins are possible on (primary key attributes as well. In the case of above Person already has a refernce to Address, so that can be used. But how do you do a one to many relationship without correct references? I want to look at a full range of MOGs to automate and semi-autimate things with regards to nested structures. At the moment there is no best practice and DRL (or any other rule language) does not make this nice. We ALL suck for compact nested accessors. The notation a.b.c reflects an implementation technique for a hierarchical data type. (Traditionally, x-dot-y means add the offset for y to the address resulting from x.) A more general concept for navigation in a data structure would have to separate a logical relationship from the implementation technique. It may be necessary to retain the dot notation for the hard coded access and to devise an entirely new notation for logical navigation. As a somewhat contrived example, assume that Address is stored as a map field with key addr and the street is the second text line of the address: declare Person name : String # default implementation as JBean field props : Map address : Address as props[addr] # the implementation end declare Address lines : String[] street : String as lines[1] end Person( name == Psmith, address/street == Main Drag ) Car( owner/address/street ... ) # Person owner Notice that explicitly using props[addr] or lines[1] is just another implementation dependent notation which breaks as soon as someone decides to change it in the class. Such things should not permeate application code. Also, notice that a navigation expression could be dynamic, making navigation dependent on the object's state, or whatever. MOGs could indeed use a different / operator to indicate that they are relational and to be treated as joins. when we come to implementing this, we'll have a wider debate on dev mailing list, as it's not happening in the next few weeks :) Just trying to give people a taste of directions we can go to improve things. Mark -W Mark -W ___ rules-users mailing list rules-users@lists.jboss.org mailto:rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users ___ rules-users mailing list rules-users@lists.jboss.org mailto:rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Condition syntax to access Map
On 29/07/2011 17:50, Greg Barton wrote: Ah, other engines don't do nested accessors because they're wimps. WIMPS! :) I'd like to see a situation where we have the convenience of nested accessors, but mapping to fully relational joins. This is combine with some nice XPATH like syntax too. Implicit mapping I call Managed Object Graphs MOGs. So you can write Person( address.street == my road ) And that internally would get translated too $p : Person() Address( person == $p, street == my road ) As there is no doubt that the current explicit bindings approach on objects is too verbose and hard to read. Nested accessors add a lot of readability. I also want to add xpath like syntax as a short cut for 'from', as I think it makes for easier readability: Bookshop()/books( author == some author ) Which is a short cut for: $b : Bookshop Book( author == some author ) from $b.books And would support map/list access like xpath: Person()/pets[0]/( age 30) Whichis short for $p : Person() Pet( owner == $p, age 30 ) from $p.pets[0] Again if the nested objects are inserted as MOGs, the joins would be obeyed instead of using 'from', i.e. they'll receive notifications from nested object update. This is partly why I think we need to have a think about syntax accessors in general, before we decide what to do, there are a lot of related areas and a decision in one area impacts another. Mark --- On *Fri, 7/29/11, Mark Proctor /mproc...@codehaus.org/* wrote: From: Mark Proctor mproc...@codehaus.org Subject: Re: [rules-users] Condition syntax to access Map To: rules-users@lists.jboss.org Date: Friday, July 29, 2011, 8:52 AM On 29/07/2011 14:28, Edson Tirelli wrote: Yes, that is exactly what I think. Pattern matching constraints are like query parameters. They need to exist and evaluate to true in order to match. So, for this to match: a.b.c == null a needs to exist and be non-null, b needs to exist and be non-null, c needs to exist and be null. So it is not just NP safe navigation... it is an existence test at the same time. So for maps a[x].b[y].c[z] == null The keys x, y and z need to exist, and c[z] must have a value of null. That is what the expression above is asking for, in my understanding. This presents no loss of completeness to the language, as you can still test non-existence of keys if that is what you want, but the most common case you are looking for the opposite and it becomes much simpler to write rules that way. So, a builder option to turn this on is allright with me. We can probably do that and have a configuration option to turn this feature on/off. I'm strongly against configuration options in this case, we decide on one way and stick with it. We already have too many configurations and a casual person looking at the code could introduce a bug as they weren't aware of what configuratino was on for null safety. I think part of the problem here is we are mixing domains, between script evaluation and relational constraints. There is a reason why other rule engines don't do nested accessors :) (ignoring the technical issues too). Mark Mark Edson 2011/7/29 Mark Proctor mproc...@codehaus.org /mc/compose?to=mproc...@codehaus.org Lets forget that these are nested accessors and the problems they bring. Lets look at what they would be if they were real relations: On 29/07/2011 08:55, Wolfgang Laun wrote: Whoa! See below... 2011/7/28 Edson Tirelli ed.tire...@gmail.com /mc/compose?to=ed.tire...@gmail.com I think we need to differentiate paradigms here. When using rules, contrary to imperative code, what we are doing is pattern matching. X( a.b.c == value ) In the above case, we are looking for Xs that make that whole constraint true (i.e. match). If a or b are null, the whole expression will be false, does not matter the value of c or the value it is being compared against. (Edson: Only if you define it so. The logical implication of c being null in an absent a.b (i.e., a.b==null) could very well be that a.b.c does not exist, and you can't claim that a.b.c exists if a.b. doesn't! Is there no house at some address? (city.street[name].house[number] == null) # true = no such house $c : City() $s : Street( city == $c, street = name ) House( number == null) The above is identical logic to the more convenient form of nested accessors, it's the proper relational form. In this case if there was no Street, it wouldn't match. This test data with false when null: Vienna/TirelliStrasse/42 returns
Re: [rules-users] Condition syntax to access Map
2011/7/31 Mark Proctor mproc...@codehaus.org Implicit mapping I call Managed Object Graphs MOGs. So you can write Person( address.street == my road ) And that internally would get translated too $p : Person() Address( person == $p, street == my road ) As there is no doubt that the current explicit bindings approach on objects is too verbose and hard to read. Nested accessors add a lot of readability. So what if Address is not an inserted fact? So far, a CE with type Foo(...) implied the existence of a fact of that type. I'm not sure that inserting some object should imply the insertion of all of its descendants as facts as well... -W ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Condition syntax to access Map
On 31/07/2011 19:39, Wolfgang Laun wrote: 2011/7/31 Mark Proctor mproc...@codehaus.org mailto:mproc...@codehaus.org Implicit mapping I call Managed Object Graphs MOGs. So you can write Person( address.street == my road ) And that internally would get translated too $p : Person() Address( person == $p, street == my road ) As there is no doubt that the current explicit bindings approach on objects is too verbose and hard to read. Nested accessors add a lot of readability. So what if Address is not an inserted fact? So far, a CE with type Foo(...) implied the existence of a fact of that type. I'm not sure that inserting some object should imply the insertion of all of its descendants as facts as well... You don't necessarily have to insert Address. It can attach a listener, assuming the pojo supported it, when it's accessed in a pattern - allowing the pattern to receive updates from nested objects. Whether something is inserted or not can be annotation driven. Something can't be inserted anyway unless it has the necessary references for the joins. I want to look at a full range of MOGs to automate and semi-autimate things with regards to nested structures. At the moment there is no best practice and DRL (or any other rule language) does not make this nice. We ALL suck for compact nested accessors. Mark -W ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Condition syntax to access Map
Whoa! See below...
2011/7/28 Edson Tirelli ed.tire...@gmail.com
I think we need to differentiate paradigms here. When using rules,
contrary to imperative code, what we are doing is pattern matching.
X( a.b.c == value )
In the above case, we are looking for Xs that make that whole constraint
true (i.e. match). If a or b are null, the whole expression will be false,
does not matter the value of c or the value it is being compared against.
(Edson: Only if you define it so. The logical implication of c being null in
an absent a.b (i.e., a.b==null) could very well be that a.b.c does not
exist, and you can't claim that a.b.c exists if a.b. doesn't!
Is there no house at some address?
(city.street[name].house[number] == null) # true = no such house
This test data with false when null: Vienna/TirelliStrasse/42 returns
false, hence there *is* such a house. But we don't have a Tirelli Street
in Vienna (yet)!
Confer this to Perl's
! exists $city{-streets}{Tirelli}[42]
)
Raising a null pointer exception, IMO, brings no advantage at all to the
table... on the contrary, makes writing rules more difficult.
Edson, Mark,... please do recall the times where you have had an NPE in the
code in a boolean expression? How painful would it have been if Java would
have returned false, continuing to cover a coding error made elsewhere?
Why don't other languages tolerate null silently? (Perl, the most
pragmatic of all, doesn't - it has introduced an operator I can use or not.)
I have no problem when folks want to take shortcuts and live la dolce vita,
but
emI don't want to be led into the bog without my consent./em
So, a builder option to turn this on is allright with me.
Another example we had in the past:
class Circle implements Shape
class Square implements Shape
rule X
when
Circle() from $shapes
...
In the above example, $shapes is a list and the rule is clearly looking
for Circles. If there are Squares in there, they will just not match.
Raising a ClassCastException like it would happen in an imperative language
brings no advantage to the table, IMO.
This is an entirely different matter than the previous one. I see no reason
whatsoever, not to define this from as working with an implicit filter.
-W
So, IMO, all property navigation should be null pointer safe in the LHS
of the rules.
This is not what happens today, but I think it should be fixed.
Edson
2011/7/28 Vincent LEGENDRE vincent.legen...@eurodecision.com
Hi all,
I agree with W. : NPE should be the default, and null cases behaviour
should be planned by programmers.
But I am not sure about using a new operator in rules (and do the update
in Guvnor ...).
Why not using some drools annotations on the getter specifying the
behaviour of an eval on a null value returned by this getter ?
And may be these annotation could be added to an existing POJO via the
declared type syntax (just like event role in fusion) ?
Vincent.
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
--
Edson Tirelli
JBoss Drools Core Development
JBoss by Red Hat @ www.jboss.com
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Condition syntax to access Map
Lets forget that these are nested accessors and the problems they bring.
Lets look at what they would be if they were real relations:
On 29/07/2011 08:55, Wolfgang Laun wrote:
Whoa! See below...
2011/7/28 Edson Tirelli ed.tire...@gmail.com
mailto:ed.tire...@gmail.com
I think we need to differentiate paradigms here. When using
rules, contrary to imperative code, what we are doing is pattern
matching.
X( a.b.c == value )
In the above case, we are looking for Xs that make that whole
constraint true (i.e. match). If a or b are null, the whole
expression will be false, does not matter the value of c or the
value it is being compared against.
(Edson: Only if you define it so. The logical implication of c being
null in an absent a.b (i.e., a.b==null) could very well be that a.b.c
does not exist, and you can't claim that a.b.c exists if a.b. doesn't!
Is there no house at some address?
(city.street[name].house[number] == null) # true = no such house
$c : City()
$s : Street( city == $c, street = name )
House( number == null)
The above is identical logic to the more convenient form of nested
accessors, it's the proper relational form. In this case if there was no
Street, it wouldn't match.
This test data with false when null: Vienna/TirelliStrasse/42 returns
false, hence there /is/ such a house. But we don't have a Tirelli
Street in Vienna (yet)!
Confer this to Perl's
! exists $city{-streets}{Tirelli}[42]
)
Raising a null pointer exception, IMO, brings no advantage at all
to the table... on the contrary, makes writing rules more difficult.
Edson, Mark,... please do recall the times where you have had an NPE
in the code in a boolean expression? How painful would it have been if
Java would have returned false, continuing to cover a coding error
made elsewhere?
Why don't other languages tolerate null silently? (Perl, the most
pragmatic of all, doesn't - it has introduced an operator I can use or
not.)
I have no problem when folks want to take shortcuts and live la dolce
vita, but
emI don't want to be led into the bog without my consent./em
So, a builder option to turn this on is allright with me.
Another example we had in the past:
class Circle implements Shape
class Square implements Shape
rule X
when
Circle() from $shapes
...
In the above example, $shapes is a list and the rule is clearly
looking for Circles. If there are Squares in there, they will just
not match. Raising a ClassCastException like it would happen in an
imperative language brings no advantage to the table, IMO.
This is an entirely different matter than the previous one. I see no
reason whatsoever, not to define this from as working with an
implicit filter.
-W
So, IMO, all property navigation should be null pointer safe in
the LHS of the rules.
This is not what happens today, but I think it should be fixed.
Edson
2011/7/28 Vincent LEGENDRE vincent.legen...@eurodecision.com
mailto:vincent.legen...@eurodecision.com
Hi all,
I agree with W. : NPE should be the default, and null cases
behaviour should be planned by programmers.
But I am not sure about using a new operator in rules (and do
the update in Guvnor ...).
Why not using some drools annotations on the getter specifying
the behaviour of an eval on a null value returned by this
getter ?
And may be these annotation could be added to an existing POJO
via the declared type syntax (just like event role in fusion) ?
Vincent.
___
rules-users mailing list
rules-users@lists.jboss.org mailto:rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
--
Edson Tirelli
JBoss Drools Core Development
JBoss by Red Hat @ www.jboss.com http://www.jboss.com
___
rules-users mailing list
rules-users@lists.jboss.org mailto:rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Condition syntax to access Map
Yes, that is exactly what I think. Pattern matching constraints are like
query parameters. They need to exist and evaluate to true in order to match.
So, for this to match:
a.b.c == null
a needs to exist and be non-null, b needs to exist and be non-null, c
needs to exist and be null. So it is not just NP safe navigation... it is an
existence test at the same time. So for maps
a[x].b[y].c[z] == null
The keys x, y and z need to exist, and c[z] must have a value of null.
That is what the expression above is asking for, in my understanding.
This presents no loss of completeness to the language, as you can still
test non-existence of keys if that is what you want, but the most common
case you are looking for the opposite and it becomes much simpler to write
rules that way.
So, a builder option to turn this on is allright with me.
We can probably do that and have a configuration option to turn this
feature on/off.
Edson
2011/7/29 Mark Proctor mproc...@codehaus.org
Lets forget that these are nested accessors and the problems they bring.
Lets look at what they would be if they were real relations:
On 29/07/2011 08:55, Wolfgang Laun wrote:
Whoa! See below...
2011/7/28 Edson Tirelli ed.tire...@gmail.com
I think we need to differentiate paradigms here. When using rules,
contrary to imperative code, what we are doing is pattern matching.
X( a.b.c == value )
In the above case, we are looking for Xs that make that whole
constraint true (i.e. match). If a or b are null, the whole expression will
be false, does not matter the value of c or the value it is being compared
against.
(Edson: Only if you define it so. The logical implication of c being null
in an absent a.b (i.e., a.b==null) could very well be that a.b.c does not
exist, and you can't claim that a.b.c exists if a.b. doesn't!
Is there no house at some address?
(city.street[name].house[number] == null) # true = no such house
$c : City()
$s : Street( city == $c, street = name )
House( number == null)
The above is identical logic to the more convenient form of nested
accessors, it's the proper relational form. In this case if there was no
Street, it wouldn't match.
This test data with false when null: Vienna/TirelliStrasse/42 returns
false, hence there *is* such a house. But we don't have a Tirelli Street
in Vienna (yet)!
Confer this to Perl's
! exists $city{-streets}{Tirelli}[42]
)
Raising a null pointer exception, IMO, brings no advantage at all to the
table... on the contrary, makes writing rules more difficult.
Edson, Mark,... please do recall the times where you have had an NPE in the
code in a boolean expression? How painful would it have been if Java would
have returned false, continuing to cover a coding error made elsewhere?
Why don't other languages tolerate null silently? (Perl, the most
pragmatic of all, doesn't - it has introduced an operator I can use or not.)
I have no problem when folks want to take shortcuts and live la dolce vita,
but
emI don't want to be led into the bog without my consent./em
So, a builder option to turn this on is allright with me.
Another example we had in the past:
class Circle implements Shape
class Square implements Shape
rule X
when
Circle() from $shapes
...
In the above example, $shapes is a list and the rule is clearly
looking for Circles. If there are Squares in there, they will just not
match. Raising a ClassCastException like it would happen in an imperative
language brings no advantage to the table, IMO.
This is an entirely different matter than the previous one. I see no reason
whatsoever, not to define this from as working with an implicit filter.
-W
So, IMO, all property navigation should be null pointer safe in the
LHS of the rules.
This is not what happens today, but I think it should be fixed.
Edson
2011/7/28 Vincent LEGENDRE vincent.legen...@eurodecision.com
Hi all,
I agree with W. : NPE should be the default, and null cases behaviour
should be planned by programmers.
But I am not sure about using a new operator in rules (and do the update
in Guvnor ...).
Why not using some drools annotations on the getter specifying the
behaviour of an eval on a null value returned by this getter ?
And may be these annotation could be added to an existing POJO via the
declared type syntax (just like event role in fusion) ?
Vincent.
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
--
Edson Tirelli
JBoss Drools Core Development
JBoss by Red Hat @ www.jboss.com
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
___
rules-users mailing
Re: [rules-users] Condition syntax to access Map
On 29/07/2011 14:28, Edson Tirelli wrote:
Yes, that is exactly what I think. Pattern matching constraints are
like query parameters. They need to exist and evaluate to true in
order to match. So, for this to match:
a.b.c == null
a needs to exist and be non-null, b needs to exist and be non-null,
c needs to exist and be null. So it is not just NP safe navigation...
it is an existence test at the same time. So for maps
a[x].b[y].c[z] == null
The keys x, y and z need to exist, and c[z] must have a value of
null. That is what the expression above is asking for, in my
understanding.
This presents no loss of completeness to the language, as you can
still test non-existence of keys if that is what you want, but the
most common case you are looking for the opposite and it becomes much
simpler to write rules that way.
So, a builder option to turn this on is allright with me.
We can probably do that and have a configuration option to turn
this feature on/off.
I'm strongly against configuration options in this case, we decide on
one way and stick with it. We already have too many configurations and a
casual person looking at the code could introduce a bug as they weren't
aware of what configuratino was on for null safety.
I think part of the problem here is we are mixing domains, between
script evaluation and relational constraints. There is a reason why
other rule engines don't do nested accessors :) (ignoring the technical
issues too).
Mark
Mark
Edson
2011/7/29 Mark Proctor mproc...@codehaus.org
mailto:mproc...@codehaus.org
Lets forget that these are nested accessors and the problems they
bring. Lets look at what they would be if they were real relations:
On 29/07/2011 08:55, Wolfgang Laun wrote:
Whoa! See below...
2011/7/28 Edson Tirelli ed.tire...@gmail.com
mailto:ed.tire...@gmail.com
I think we need to differentiate paradigms here. When
using rules, contrary to imperative code, what we are doing
is pattern matching.
X( a.b.c == value )
In the above case, we are looking for Xs that make that
whole constraint true (i.e. match). If a or b are null, the
whole expression will be false, does not matter the value of
c or the value it is being compared against.
(Edson: Only if you define it so. The logical implication of c
being null in an absent a.b (i.e., a.b==null) could very well be
that a.b.c does not exist, and you can't claim that a.b.c
exists if a.b. doesn't!
Is there no house at some address?
(city.street[name].house[number] == null) # true = no such
house
$c : City()
$s : Street( city == $c, street = name )
House( number == null)
The above is identical logic to the more convenient form of nested
accessors, it's the proper relational form. In this case if there
was no Street, it wouldn't match.
This test data with false when null: Vienna/TirelliStrasse/42
returns false, hence there /is/ such a house. But we don't have
a Tirelli Street in Vienna (yet)!
Confer this to Perl's
! exists $city{-streets}{Tirelli}[42]
)
Raising a null pointer exception, IMO, brings no advantage at
all to the table... on the contrary, makes writing rules more
difficult.
Edson, Mark,... please do recall the times where you have had an
NPE in the code in a boolean expression? How painful would it
have been if Java would have returned false, continuing to
cover a coding error made elsewhere?
Why don't other languages tolerate null silently? (Perl, the
most pragmatic of all, doesn't - it has introduced an operator I
can use or not.)
I have no problem when folks want to take shortcuts and live la
dolce vita, but
emI don't want to be led into the bog without my consent./em
So, a builder option to turn this on is allright with me.
Another example we had in the past:
class Circle implements Shape
class Square implements Shape
rule X
when
Circle() from $shapes
...
In the above example, $shapes is a list and the rule is
clearly looking for Circles. If there are Squares in there,
they will just not match. Raising a ClassCastException like
it would happen in an imperative language brings no advantage
to the table, IMO.
This is an entirely different matter than the previous one. I see
no reason whatsoever, not to define this from as working with
an implicit filter.
-W
So, IMO, all property navigation should be null pointer
safe in the LHS of the rules.
This is not what happens today, but I think it should be
fixed.
Edson
2011/7/28 Vincent LEGENDRE vincent.legen...@eurodecision.com
Re: [rules-users] Condition syntax to access Map
Ah, other engines don't do nested accessors because they're wimps. WIMPS! :) --- On Fri, 7/29/11, Mark Proctor mproc...@codehaus.org wrote: From: Mark Proctor mproc...@codehaus.org Subject: Re: [rules-users] Condition syntax to access Map To: rules-users@lists.jboss.org Date: Friday, July 29, 2011, 8:52 AM On 29/07/2011 14:28, Edson Tirelli wrote: Yes, that is exactly what I think. Pattern matching constraints are like query parameters. They need to exist and evaluate to true in order to match. So, for this to match: a.b.c == null a needs to exist and be non-null, b needs to exist and be non-null, c needs to exist and be null. So it is not just NP safe navigation... it is an existence test at the same time. So for maps a[x].b[y].c[z] == null The keys x, y and z need to exist, and c[z] must have a value of null. That is what the expression above is asking for, in my understanding. This presents no loss of completeness to the language, as you can still test non-existence of keys if that is what you want, but the most common case you are looking for the opposite and it becomes much simpler to write rules that way. So, a builder option to turn this on is allright with me. We can probably do that and have a configuration option to turn this feature on/off. I'm strongly against configuration options in this case, we decide on one way and stick with it. We already have too many configurations and a casual person looking at the code could introduce a bug as they weren't aware of what configuratino was on for null safety. I think part of the problem here is we are mixing domains, between script evaluation and relational constraints. There is a reason why other rule engines don't do nested accessors :) (ignoring the technical issues too). Mark Mark Edson 2011/7/29 Mark Proctor mproc...@codehaus.org Lets forget that these are nested accessors and the problems they bring. Lets look at what they would be if they were real relations: On 29/07/2011 08:55, Wolfgang Laun wrote: Whoa! See below... 2011/7/28 Edson Tirelli ed.tire...@gmail.com I think we need to differentiate paradigms here. When using rules, contrary to imperative code, what we are doing is pattern matching. X( a.b.c == value ) In the above case, we are looking for Xs that make that whole constraint true (i.e. match). If a or b are null, the whole expression will be false, does not matter the value of c or the value it is being compared against. (Edson: Only if you define it so. The logical implication of c being null in an absent a.b (i.e., a.b==null) could very well be that a.b.c does not exist, and you can't claim that a.b.c exists if a.b. doesn't! Is there no house at some address? (city.street[name].house[number] == null) # true = no such house $c : City() $s : Street( city == $c, street = name ) House( number == null) The above is identical logic to the more convenient form of nested accessors, it's the proper relational form. In this case if there was no Street, it wouldn't match. This test data with false when null: Vienna/TirelliStrasse/42 returns false, hence there is such a house. But we don't have a Tirelli Street in Vienna (yet)! Confer this to Perl's
Re: [rules-users] Condition syntax to access Map
Mark Thanks for the info - although it was not actually the solution to my problem, it prompted me to look again at my assertion that there were not any null values. In actual fact answerData[0] was null ( I should have been checking for answerData[100]) and this was causing the error. You modified syntax is much tidier; I'm now using the following format: $a : Answer(answerData[0] != null answerData[0].value_str == Valves) This prevents the prior null pointer exception. Thanks for your input. David -- View this message in context: http://drools.46999.n3.nabble.com/Condition-syntax-to-access-Map-tp3204429p3205961.html Sent from the Drools: User forum mailing list archive at Nabble.com. ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Condition syntax to access Map
On 28/07/2011 08:26, bolsover wrote:
Mark
Thanks for the info - although it was not actually the solution to my
problem, it prompted me to look again at my assertion that there were not
any null values. In actual fact answerData[0] was null ( I should have been
checking for answerData[100]) and this was causing the error.
You modified syntax is much tidier; I'm now using the following format:
$a : Answer(answerData[0] != null answerData[0].value_str == Valves)
I'm not sure it's supported in our parser, but I think we should do it -
either add support for it, or make it implement to the . accessor.
MVEL supports null safe navigation, which means it'll return false if a
null value is returned from an accessor.
http://mvel.codehaus.org/MVEL+2.0+Property+Navigation
Sometimes you have property expressions which may contain a null
element, requiring you to create a null-check. You can simplify this by
using the null-safe operator:
user.?manager.name
This is functionally equivalent to writing:
if (user.manager !=null) {return user.manager.name; }else {return null; }
I doubt there is a time when someone wants a nullpointer to happen. So
maybe we should build this in as default into expressions. I guess the
only time we shouldn't is if people know it will enver be null and don't
want the small overad for the null check.
What do people think?
Mark
This prevents the prior null pointer exception.
Thanks for your input.
David
--
View this message in context:
http://drools.46999.n3.nabble.com/Condition-syntax-to-access-Map-tp3204429p3205961.html
Sent from the Drools: User forum mailing list archive at Nabble.com.
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Condition syntax to access Map
Thanks for the pointer to the MVEL documents - I can forsee null-safe operator user.?manager.name syntax being most useful. As for making the null test the default action - I'm not sure - I can't say I have ever actually 'wanted' a nullpointer - but there may be some special case. David -- View this message in context: http://drools.46999.n3.nabble.com/Condition-syntax-to-access-Map-tp3204429p3206467.html Sent from the Drools: User forum mailing list archive at Nabble.com. ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Condition syntax to access Map
Two points to consider: (1) If a programmer writes a.getB().getC() == something and a NPE happens due to a.getB() == null we may distinguish (a) and (b) - see below. (a) The setup is so that this is to be expected but the programmer forgot to take this possibility into account. Then we have: (a1) The consequence of a.getB() == null should be the same as a.getB().getC() == null. (a2) If a.getB() == null, something else needs to be done, e.g., a.setB(x). If this is silently covered by the system, the absence of handling will not be detected so easily. (b) The assumption is that a.getB() should never be == null in the first place, but some other error (in data or code) caused this. If this is silently covered by the system, this error will not be detected so easily. (2) If a.getB().getC() == something returns false if a.getB() is null, is this also the desired result if something is null, i.e., do you want a.getB().getC() == null to be false if a.getB() == null ? Null safe navigation is a nice try and *may* be tolerable, but it should never be the default. -W On 28 July 2011 14:06, bolsover da...@bolsover.com wrote: Thanks for the pointer to the MVEL documents - I can forsee null-safe operator user.?manager.name syntax being most useful. As for making the null test the default action - I'm not sure - I can't say I have ever actually 'wanted' a nullpointer - but there may be some special case. David -- View this message in context: http://drools.46999.n3.nabble.com/Condition-syntax-to-access-Map-tp3204429p3206467.html Sent from the Drools: User forum mailing list archive at Nabble.com. ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Condition syntax to access Map
On 28/07/2011 13:53, Wolfgang Laun wrote: Two points to consider: (1) If a programmer writes a.getB().getC() == something and a NPE happens due to a.getB() == null we may distinguish (a) and (b) - see below. (a) The setup is so that this is to be expected but the programmer forgot to take this possibility into account. Then we have: (a1) The consequence of a.getB() == null should be the same as a.getB().getC() == null. (a2) If a.getB() == null, something else needs to be done, e.g., a.setB(x). If this is silently covered by the system, the absence of handling will not be detected so easily. (b) The assumption is that a.getB() should never be == null in the first place, but some other error (in data or code) caused this. If this is silently covered by the system, this error will not be detected so easily. (2) If a.getB().getC() == something returns false if a.getB() is null, is this also the desired result if something is null, i.e., do you want a.getB().getC() == null to be false if a.getB() == null ? Null safe navigation is a nice try and *may* be tolerable, but it should never be the default. ok, sounds like we just need to add .? support into our parser then - if it's not already supported. Mark -W On 28 July 2011 14:06, bolsover da...@bolsover.com mailto:da...@bolsover.com wrote: Thanks for the pointer to the MVEL documents - I can forsee null-safe operator user.?manager.name http://manager.name syntax being most useful. As for making the null test the default action - I'm not sure - I can't say I have ever actually 'wanted' a nullpointer - but there may be some special case. David -- View this message in context: http://drools.46999.n3.nabble.com/Condition-syntax-to-access-Map-tp3204429p3206467.html Sent from the Drools: User forum mailing list archive at Nabble.com. ___ rules-users mailing list rules-users@lists.jboss.org mailto:rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Condition syntax to access Map
Hi all, I agree with W. : NPE should be the default, and null cases behaviour should be planned by programmers. But I am not sure about using a new operator in rules (and do the update in Guvnor ...). Why not using some drools annotations on the getter specifying the behaviour of an eval on a null value returned by this getter ? And may be these annotation could be added to an existing POJO via the declared type syntax (just like event role in fusion) ? Vincent. ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Condition syntax to access Map
All, I think we need to differentiate paradigms here. When using rules, contrary to imperative code, what we are doing is pattern matching. X( a.b.c == value ) In the above case, we are looking for Xs that make that whole constraint true (i.e. match). If a or b are null, the whole expression will be false, does not matter the value of c or the value it is being compared against. Raising a null pointer exception, IMO, brings no advantage at all to the table... on the contrary, makes writing rules more difficult. Another example we had in the past: class Circle implements Shape class Square implements Shape rule X when Circle() from $shapes ... In the above example, $shapes is a list and the rule is clearly looking for Circles. If there are Squares in there, they will just not match. Raising a ClassCastException like it would happen in an imperative language brings no advantage to the table, IMO. So, IMO, all property navigation should be null pointer safe in the LHS of the rules. This is not what happens today, but I think it should be fixed. Edson 2011/7/28 Vincent LEGENDRE vincent.legen...@eurodecision.com Hi all, I agree with W. : NPE should be the default, and null cases behaviour should be planned by programmers. But I am not sure about using a new operator in rules (and do the update in Guvnor ...). Why not using some drools annotations on the getter specifying the behaviour of an eval on a null value returned by this getter ? And may be these annotation could be added to an existing POJO via the declared type syntax (just like event role in fusion) ? Vincent. ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users -- Edson Tirelli JBoss Drools Core Development JBoss by Red Hat @ www.jboss.com ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Condition syntax to access Map
+1 Naw +billion --- On Thu, 7/28/11, Edson Tirelli ed.tire...@gmail.com wrote: From: Edson Tirelli ed.tire...@gmail.com Subject: Re: [rules-users] Condition syntax to access Map To: Rules Users List rules-users@lists.jboss.org Date: Thursday, July 28, 2011, 1:13 PM All, I think we need to differentiate paradigms here. When using rules, contrary to imperative code, what we are doing is pattern matching. X( a.b.c == value ) In the above case, we are looking for Xs that make that whole constraint true (i.e. match). If a or b are null, the whole expression will be false, does not matter the value of c or the value it is being compared against. Raising a null pointer exception, IMO, brings no advantage at all to the table... on the contrary, makes writing rules more difficult. Another example we had in the past: class Circle implements Shapeclass Square implements Shape rule Xwhen Circle() from $shapes ... In the above example, $shapes is a list and the rule is clearly looking for Circles. If there are Squares in there, they will just not match. Raising a ClassCastException like it would happen in an imperative language brings no advantage to the table, IMO. So, IMO, all property navigation should be null pointer safe in the LHS of the rules. This is not what happens today, but I think it should be fixed. Edson 2011/7/28 Vincent LEGENDRE vincent.legen...@eurodecision.com Hi all, I agree with W. : NPE should be the default, and null cases behaviour should be planned by programmers. But I am not sure about using a new operator in rules (and do the update in Guvnor ...). Why not using some drools annotations on the getter specifying the behaviour of an eval on a null value returned by this getter ? And may be these annotation could be added to an existing POJO via the declared type syntax (just like event role in fusion) ? Vincent. ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users -- Edson Tirelli JBoss Drools Core Development JBoss by Red Hat @ www.jboss.com -Inline Attachment Follows- ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Condition syntax to access Map
if we do implicit .? support people will still be able to do null checks. So it's not one or the other. Mark On 28/07/2011 20:07, Greg Barton wrote: +1 Naw +billion --- On *Thu, 7/28/11, Edson Tirelli /ed.tire...@gmail.com/* wrote: From: Edson Tirelli ed.tire...@gmail.com Subject: Re: [rules-users] Condition syntax to access Map To: Rules Users List rules-users@lists.jboss.org Date: Thursday, July 28, 2011, 1:13 PM All, I think we need to differentiate paradigms here. When using rules, contrary to imperative code, what we are doing is pattern matching. X( a.b.c == value ) In the above case, we are looking for Xs that make that whole constraint true (i.e. match). If a or b are null, the whole expression will be false, does not matter the value of c or the value it is being compared against. Raising a null pointer exception, IMO, brings no advantage at all to the table... on the contrary, makes writing rules more difficult. Another example we had in the past: class Circle implements Shape class Square implements Shape rule X when Circle() from $shapes ... In the above example, $shapes is a list and the rule is clearly looking for Circles. If there are Squares in there, they will just not match. Raising a ClassCastException like it would happen in an imperative language brings no advantage to the table, IMO. So, IMO, all property navigation should be null pointer safe in the LHS of the rules. This is not what happens today, but I think it should be fixed. Edson 2011/7/28 Vincent LEGENDRE vincent.legen...@eurodecision.com /mc/compose?to=vincent.legen...@eurodecision.com Hi all, I agree with W. : NPE should be the default, and null cases behaviour should be planned by programmers. But I am not sure about using a new operator in rules (and do the update in Guvnor ...). Why not using some drools annotations on the getter specifying the behaviour of an eval on a null value returned by this getter ? And may be these annotation could be added to an existing POJO via the declared type syntax (just like event role in fusion) ? Vincent. ___ rules-users mailing list rules-users@lists.jboss.org /mc/compose?to=rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users -- Edson Tirelli JBoss Drools Core Development JBoss by Red Hat @ www.jboss.com http://www.jboss.com -Inline Attachment Follows- ___ rules-users mailing list rules-users@lists.jboss.org /mc/compose?to=rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Condition syntax to access Map
I'm 100% with Edson on this one. Requiring explicit syntax, whether via null checks or .?, can have a big impact on the clarity and level of declarativeness (word?) of a given ruleset. It also makes it a great deal harder to develop DSLs and systems to put rules into the hands of non-developers because then you're requiring those users to bring with them the imperative programming mindset of checking every data point before using it. I think that Edson's example of making the whole expression false if any object on the call stack is null independent of the value is an excellent convention. Joe From: rules-users-boun...@lists.jboss.org [mailto:rules-users-boun...@lists.jboss.org] On Behalf Of Mark Proctor Sent: Thursday, July 28, 2011 1:35 PM To: rules-users@lists.jboss.org Subject: Re: [rules-users] Condition syntax to access Map if we do implicit .? support people will still be able to do null checks. So it's not one or the other. Mark On 28/07/2011 20:07, Greg Barton wrote: +1 Naw +billion --- On Thu, 7/28/11, Edson Tirelli ed.tire...@gmail.com mailto:ed.tire...@gmail.com wrote: From: Edson Tirelli ed.tire...@gmail.com mailto:ed.tire...@gmail.com Subject: Re: [rules-users] Condition syntax to access Map To: Rules Users List rules-users@lists.jboss.org mailto:rules-users@lists.jboss.org Date: Thursday, July 28, 2011, 1:13 PM All, I think we need to differentiate paradigms here. When using rules, contrary to imperative code, what we are doing is pattern matching. X( a.b.c == value ) In the above case, we are looking for Xs that make that whole constraint true (i.e. match). If a or b are null, the whole expression will be false, does not matter the value of c or the value it is being compared against. Raising a null pointer exception, IMO, brings no advantage at all to the table... on the contrary, makes writing rules more difficult. Another example we had in the past: class Circle implements Shape class Square implements Shape rule X when Circle() from $shapes ... In the above example, $shapes is a list and the rule is clearly looking for Circles. If there are Squares in there, they will just not match. Raising a ClassCastException like it would happen in an imperative language brings no advantage to the table, IMO. So, IMO, all property navigation should be null pointer safe in the LHS of the rules. This is not what happens today, but I think it should be fixed. Edson 2011/7/28 Vincent LEGENDRE vincent.legen...@eurodecision.com Hi all, I agree with W. : NPE should be the default, and null cases behaviour should be planned by programmers. But I am not sure about using a new operator in rules (and do the update in Guvnor ...). Why not using some drools annotations on the getter specifying the behaviour of an eval on a null value returned by this getter ? And may be these annotation could be added to an existing POJO via the declared type syntax (just like event role in fusion) ? Vincent. ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users -- Edson Tirelli JBoss Drools Core Development JBoss by Red Hat @ www.jboss.com -Inline Attachment Follows- ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
[rules-users] Condition syntax to access Map
I'm struggling with the syntax to access a mapped object - hoping that
someone can help with this..
I have the following condition in a rule:
$a : Answer(getAnswerData().get(0).getValue_str() == Valves)
Answer is a pojo where answerData is a Maplt;Integer, AnswerDatagt;
object.
AnswerData is also a pojo and has a String variable value_str.
Rule containing this condition complies but I get the following error when I
fireAllRules
[Error: null pointer or function not found: getValue_str]
[Near : {... getAnswerData().get(0).getValu }]
^
[Line: 1, Column: 1]
org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getMethod(ReflectiveAccessorOptimizer.java:997)
The method getValue_str() does exist in AnswerData as does getAnswerData()
in Answer and there are not any null values.
I'm assuming that autoboxing will correctly interpret .get(0) as an Integer
object.
Any ideas??
--
View this message in context:
http://drools.46999.n3.nabble.com/Condition-syntax-to-access-Map-tp3204429p3204429.html
Sent from the Drools: User forum mailing list archive at Nabble.com.
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Condition syntax to access Map
On 27/07/2011 19:45, bolsover wrote:
I'm struggling with the syntax to access a mapped object - hoping that
someone can help with this..
I have the following condition in a rule:
$a : Answer(getAnswerData().get(0).getValue_str() == Valves)
try Drools 5.2 and you should be able to do
Answer( answerData[0].value_str == valves )
Mark
Answer is a pojo where answerData is a Maplt;Integer, AnswerDatagt;
object.
AnswerData is also a pojo and has a String variable value_str.
Rule containing this condition complies but I get the following error when I
fireAllRules
[Error: null pointer or function not found: getValue_str]
[Near : {... getAnswerData().get(0).getValu }]
^
[Line: 1, Column: 1]
org.mvel2.optimizers.impl.refl.ReflectiveAccessorOptimizer.getMethod(ReflectiveAccessorOptimizer.java:997)
The method getValue_str() does exist in AnswerData as does getAnswerData()
in Answer and there are not any null values.
I'm assuming that autoboxing will correctly interpret .get(0) as an Integer
object.
Any ideas??
--
View this message in context:
http://drools.46999.n3.nabble.com/Condition-syntax-to-access-Map-tp3204429p3204429.html
Sent from the Drools: User forum mailing list archive at Nabble.com.
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
