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()
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
2007/12/14, Waruzjan Shahbazian <wshahbazian(a)xiam.nl>:
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.
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:
> 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
> backward compatibility, we can't guarantee there will be no breaks,
> are always adding new features and the descriptor model must usually
> to support them what may eventually break backward compatibility. Even
> that, I think it is an affordable cost to pay (fixing eventual breaks on
> version updates) compared to your runtime application robustness.
> 2007/12/14, Waruzjan Shahbazian <wshahbazian(a)xiam.nl>:
>> 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()
>> 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,
>> 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
>> 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
>> 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
>> Edson Tirelli schreef:
>>> Yes, you may use matches. The other alternative is using an eval
>>> regular indexOf() call to check for the existance of the substring.
>>> 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
>>> 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,
>>> better. :)
>>> It is not possible to capture groups and reuse in the RHS. I'm
>>> 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.
>>> 2007/12/14, Waruzjan Shahbazian <wshahbazian(a)xiam.nl>:
>>>> 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
>>>> capturing groups and than use the results of the groups in the RHS?
>>>> not, what is the best methode to do that?
>>>> rules-users mailing list
>>> rules-users mailing list
>> rules-users mailing list
> rules-users mailing list
rules-users mailing list
JBoss Drools Core Development
Office: +55 11 3529-6000
Mobile: +55 11 9287-5646
JBoss, a division of Red Hat @