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