<br> Oh, and I missed another important difference: eval() always generates code in java dialect, while operators are resolved directly, without the need to generate code... so besides syntax sugar, there is a small gain in compilation time performance.
<br><br> []s<br> Edson<br><br><div><span class="gmail_quote">2007/12/14, Edson Tirelli <<a href="mailto:tirelli@post.com">tirelli@post.com</a>>:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br> The difference is not in sharing the nodes, but in indexing... although, today, only "==" constraints are indexed.<br> So, "matches" operator is really just syntax sugar on String.matches() method call.
<br> In other words, if you have 2 rules with identical eval() calls, they may be shared, the same way that if you have 2 rules with identical "matches" call. Although, none of them is indexed and if we implement optimizations in the future drools versions, "matches" is more likely to be optimized than eval.
<div><span class="e" id="q_116d9313216e6643_1"><br><br> Edson<br><br><div><span class="gmail_quote">2007/12/14, Waruzjan Shahbazian <<a href="mailto:wshahbazian@xiam.nl" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
wshahbazian@xiam.nl</a>>:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
The pluggable operators example looks very cool :-) , I just have one<br>more question about the performance. I suppose that if I use eval() with<br>indexOf(), there would be no caching? Isn't that one of the benefits of
<br>using the "drools" operators, since ( if they work on the same way as in<br>the example in the trunk anyway) they do use caching. Anyway, if I do<br>some benchmarks about this I would let you now!<br><br>About the backwards compatibility: Thats cool, as long as what I did was
<br>not a not recommended way. The costes for the few possible changes in<br>the feature are indeed affordable to pay.<br><br>Waruzjan<br><br>Edson Tirelli schreef:<br>> I really don't know about perf differences in this case. I guess best
<br>> thing would be for you do give a try (and let us know please). :) It<br>> probably will depend on the java implementation of the matches() against<br>> indexOf() method. I guess indexOf is faster, but don't know if it is
<br>> significant difference.<br>> Regarding pluggable operators, here you have one example:<br>><br>> <a href="http://anonsvn.labs.jboss.com/labs/jbossrules/trunk/drools-core/src/main/java/org/drools/base/evaluators/MatchesEvaluatorsDefinition.java" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
http://anonsvn.labs.jboss.com/labs/jbossrules/trunk/drools-core/src/main/java/org/drools/base/evaluators/MatchesEvaluatorsDefinition.java</a><br>><br>> Regarding using the descriptor classes, I would say it is the
<br>> recommended way for generated rules, since you avoid the "text<br>> generation"+"parsing" cost of the rules. Although, as much as we try to keep<br>> backward compatibility, we can't guarantee there will be no breaks, since we
<br>> are always adding new features and the descriptor model must usually change<br>> to support them what may eventually break backward compatibility. Even with<br>> that, I think it is an affordable cost to pay (fixing eventual breaks on
<br>> version updates) compared to your runtime application robustness.<br>><br>> []s<br>> Edson<br>><br>><br>><br>> 2007/12/14, Waruzjan Shahbazian <<a href="mailto:wshahbazian@xiam.nl" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
wshahbazian@xiam.nl
</a>>:<br>><br>>> Hi,<br>>><br>>> Thanks for the reply. I wanted to be sure that there wasn't any more<br>>> efficient way to check a substring in a string, or do you think that<br>>> eval() with a indexOf() call would be more efficient than matches() with
<br>>> regular expression?. Since I can't group the results, the speed is the<br>>> only issue here.<br>>><br>>> In my application I am creating the PackageDescr myself with some<br>>> "template" RuleDescr's (which are being filled in with the, limited,
<br>>> user input in the Swing GUI) and the package is being build with the<br>>> builder. If the regular expression methode in the matches operator is<br>>> the best way to check a substring in a string, I can use variabeles
<br>>> (which are the user inputs) to fill the regular expression. So I don't<br>>> really need a new operator for this. But I am interessted how the<br>>> development of a new operator would be, so maybe you could tell me where
<br>>> I need to be to do so :-) .<br>>><br>>> In the attachment is the classe diagram of the PackageDescr with the<br>>> linked classes as I have understood and used in my application. Of<br>>> course not every operation and attribute is included, but maybe this
<br>>> could be helpfull for someone else who wants to create PackageDescr's<br>>> directly.<br>>><br>>> I suppose the public methodes used in this operation are going to be<br>>> supported by the following drools versions? Or should I have used the
<br>>> DRL and XML ? =-O<br>>><br>>> Thanks,<br>>><br>>> Waruzjan<br>>><br>>> Edson Tirelli schreef:<br>>><br>>>> Yes, you may use matches. The other alternative is using an eval and
<br>>>><br>>> a<br>>><br>>>> regular indexOf() call to check for the existance of the substring.<br>>>><br>>> Drools<br>>><br>>>> up to versions 4.0.x is JSE 1.4
compliant, so you can't use contains()<br>>>> method. In trunk, you may also develop your own operator and plug it<br>>>><br>>> into<br>>><br>>>> the engine... although, it is not documented yet, but if you want to
<br>>>><br>>> try, I<br>>><br>>>> can guide you through. And if you want to contribute docs after that,<br>>>><br>>> even<br>>><br>>>> better. :)<br>>>>
<br>>>> It is not possible to capture groups and reuse in the RHS. I'm<br>>>><br>>> thinking<br>>><br>>>> about a way to bind variables to arbitrary values in the LHS. If we<br>
>>> implement that, than it would be possible for you to do that, but not<br>>>> possible at this moment.<br>>>><br>>>> Edson<br>>>><br>>>> 2007/12/14, Waruzjan Shahbazian <
<a href="mailto:wshahbazian@xiam.nl" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">wshahbazian@xiam.nl</a>>:<br>>>><br>>>><br>>>>> Hi,<br>>>>><br>>>>> I need to check in the LHS of my rule if a given String contains an
<br>>>>> given substring. What is the best way to do that? I can use regular<br>>>>> expression with matches, but is that the best (fastest) solution?<br>>>>> (STRING matches "(?i).*SUBSTRING.*"). And can I use regulare
<br>>>>><br>>> expressions<br>>><br>>>>> capturing groups and than use the results of the groups in the RHS? If<br>>>>> not, what is the best methode to do that?<br>>>>>
<br>>>>> Thanks,<br>>>>><br>>>>> Waruzjan<br>>>>> _______________________________________________<br>>>>> rules-users mailing list<br>>>>> <a href="mailto:rules-users@lists.jboss.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
rules-users@lists.jboss.org</a><br>>>>> <a href="https://lists.jboss.org/mailman/listinfo/rules-users" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">https://lists.jboss.org/mailman/listinfo/rules-users
</a><br>>>>><br>>>>><br>>>>>
<br>>>><br>>>><br>>>> ------------------------------------------------------------------------<br>>>><br>>>> _______________________________________________<br>>>> rules-users mailing list
<br>>>> <a href="mailto:rules-users@lists.jboss.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">rules-users@lists.jboss.org</a><br>>>> <a href="https://lists.jboss.org/mailman/listinfo/rules-users" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
https://lists.jboss.org/mailman/listinfo/rules-users
</a><br>>>><br>>>><br>>> _______________________________________________<br>>> rules-users mailing list<br>>> <a href="mailto:rules-users@lists.jboss.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
rules-users@lists.jboss.org</a>
<br>>> <a href="https://lists.jboss.org/mailman/listinfo/rules-users" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">https://lists.jboss.org/mailman/listinfo/rules-users</a><br>>><br>>>
<br>>><br>>><br>><br>><br>><br>> ------------------------------------------------------------------------
<br>><br>> _______________________________________________<br>> rules-users mailing list<br>> <a href="mailto:rules-users@lists.jboss.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
rules-users@lists.jboss.org</a><br>> <a href="https://lists.jboss.org/mailman/listinfo/rules-users" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
https://lists.jboss.org/mailman/listinfo/rules-users</a><br>><br><br>_______________________________________________<br>rules-users mailing list<br><a href="mailto:rules-users@lists.jboss.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
rules-users@lists.jboss.org
</a><br><a href="https://lists.jboss.org/mailman/listinfo/rules-users" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">https://lists.jboss.org/mailman/listinfo/rules-users</a><br></blockquote></div>
<br><br clear="all"><br></span></div><div><span class="e" id="q_116d9313216e6643_2">-- <br> Edson Tirelli<br> JBoss Drools Core Development
<br> Office: +55 11 3529-6000<br> Mobile: +55 11 9287-5646<br> JBoss, a division of Red Hat @ <a href="http://www.jboss.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">www.jboss.com</a>
</span></div></blockquote></div><br><br clear="all"><br>-- <br> Edson Tirelli<br> JBoss Drools Core Development<br> Office: +55 11 3529-6000<br> Mobile: +55 11 9287-5646<br> JBoss, a division of Red Hat @ <a href="http://www.jboss.com">
www.jboss.com</a>