11:54 p.m.
What are the benefits of using pluggable operators (implementations of
org.drools.base.evaluators.EvaluatorDefinition such str, matches, or before) versus simply
making an equivalent function call? I've read the Creating pluggable
operators<http://blog.athico.com/2010/06/creating-pluggable-oprators.h... blog
post. Apart from saying that the Eclipse plugin can recognize these operators, it
doesn't really make a case for why I'd want to create my own implementation. One
might argue that operators enhance reusability, but a static method offers much the same
benefit. Does a pluggable operator have any optimization, caching, or other advantage?
For example, here are two ways to match the start of a string in a property of a fact, one
using the "str[startsWith]" operator and another with Java's
String.startsWith method:
declare Fact
key : String @key
end
rule "Use operator"
when
Fact(key str[startsWith] "abc")
then
// do something
end
rule "Use method"
when
Fact(key.startsWith("abc"))
then
// do something
end
Does one of these perform better than the other?
Best wishes,
Tom
2:03 a.m.
Thomas,
Pluggable operators were developed much before we supported free form
expressions, but nowadays they can be used for the same purpose. It is then
a matter of preference basically. You can still develop and use pluggable
operators if that makes your rule more readable by hiding complexity
related to parameter passing or something that would be required in a
method call, but I can't think of any advantage or disadvantage in either
approach in terms of performance or cost.
If I remember correctly, pluggable operators were developed for Drools
4.0, while free form expressions were only fully functional in 5.3+
(limited functionality in 5.2).
Edson
On Fri, May 24, 2013 at 10:54 AM, Thomas Grayson <tgrayson(a)bluemetal.com>wrote:
What are the benefits of using pluggable operators (implementations
of
org.drools.base.evaluators.EvaluatorDefinition such str, matches, or
before) versus simply making an equivalent function call? I’ve read the Creating
pluggable
operators<http://blog.athico.com/2010/06/creating-pluggable-oprators.h... post.
Apart from saying that the Eclipse plugin can recognize these
operators, it doesn’t really make a case for why I’d want to create my own
implementation. One might argue that operators enhance reusability, but a
static method offers much the same benefit. Does a pluggable operator have
any optimization, caching, or other advantage?****
** **
For example, here are two ways to match the start of a string in a
property of a fact, one using the “str[startsWith]” operator and another
with Java’s String.startsWith method:****
** **
*declare* Fact****
key : String @key****
*end*****
** **
*rule* "Use operator"****
*when*****
Fact(key str[startsWith] "abc")****
*then*****
// do something****
*end*****
** **
*rule* "Use method"****
*when*****
Fact(key.startsWith("abc"))****
*then*****
// do something****
*end*****
** **
Does one of these perform better than the other?****
** **
Best wishes,****
Tom****
** **
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
--
Edson Tirelli
JBoss Drools Core Development
JBoss by Red Hat @ www.jboss.com
4:51 a.m.
I'm inclined to think that a well-implemented operator can provide a
little bit more "cushioning" for the rule author. In the given
example, key.startsWith("abc") would throw an NPE if key is null. The
operator silently handle this case and simply return false.
Another thing is that operators can be used with the "single left hand
side" expression pattern, i.e.,
field opa x || opb y || opc y
Syntactic sugar, certainly, but occasionally quite convenient.
-W
On 24/05/2013, Edson Tirelli <ed.tirelli(a)gmail.com> wrote:
Thomas,
Pluggable operators were developed much before we supported free form
expressions, but nowadays they can be used for the same purpose. It is then
a matter of preference basically. You can still develop and use pluggable
operators if that makes your rule more readable by hiding complexity
related to parameter passing or something that would be required in a
method call, but I can't think of any advantage or disadvantage in either
approach in terms of performance or cost.
If I remember correctly, pluggable operators were developed for Drools
4.0, while free form expressions were only fully functional in 5.3+
(limited functionality in 5.2).
Edson
On Fri, May 24, 2013 at 10:54 AM, Thomas Grayson
<tgrayson(a)bluemetal.com>wrote:
> What are the benefits of using pluggable operators (implementations of
> org.drools.base.evaluators.EvaluatorDefinition such str, matches, or
> before) versus simply making an equivalent function call? I’ve read the
> Creating
> pluggable
> operators<http://blog.athico.com/2010/06/creating-pluggable-oprators.h...
> post. Apart from saying that the Eclipse plugin can recognize these
> operators, it doesn’t really make a case for why I’d want to create my
> own
> implementation. One might argue that operators enhance reusability, but
> a
> static method offers much the same benefit. Does a pluggable operator
> have
> any optimization, caching, or other advantage?****
>
> ** **
>
> For example, here are two ways to match the start of a string in a
> property of a fact, one using the “str[startsWith]” operator and another
> with Java’s String.startsWith method:****
>
> ** **
>
> *declare* Fact****
>
> key : String @key****
>
> *end*****
>
> ** **
>
> *rule* "Use operator"****
>
> *when*****
>
> Fact(key str[startsWith] "abc")****
>
> *then*****
>
> // do something****
>
> *end*****
>
> ** **
>
> *rule* "Use method"****
>
> *when*****
>
> Fact(key.startsWith("abc"))****
>
> *then*****
>
> // do something****
>
> *end*****
>
> ** **
>
> Does one of these perform better than the other?****
>
> ** **
>
> Best wishes,****
>
> Tom****
>
> ** **
>
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
--
Edson Tirelli
JBoss Drools Core Development
JBoss by Red Hat @ www.jboss.com
4002
days inactive
4002
days old
2 comments
3 participants
participants (3)
-
Edson Tirelli -
Thomas Grayson -
Wolfgang Laun