   Hi Michael,

   I was not able to reproduce the problem in JIRA-1766. If you still see the issue, can you please re-open the issue attaching a test case or modifying the test case I added for that issue?

   Regarding your questions:

1) I think you already got it, but look, for instance at the MatchesEvaluatorsDefinition. It will give you a simple example on how to proceed. The idea behind that is that we need the Operators to be readily available from a registry, so that the parser can easily find them. That is why I used a static cache approach, where as soon as a EvaluatorsDefinition class is loaded, it will make a call to the static cache publishing its operators.

2) The multiplicity of classes is inherited from how operators were implemented in 4.0.x.You obviously don't need to do that. As single class can implement multiple operators ****as long as the class is stateless****. This is the only requirement, really: being stateless (kind of using the fly weight pattern). For an example, look at the file SetEvaluatorsDefinition and look at the BaseMemberOf inner class. So, all the logic is in there, but we still used subclasses just to set the constructor attributes and override the toString() method, but you could still implement everything in a single class I guess.
   Also, please remember that accessors and operators are the single most stressed piece of codes in the engine, so, if you need performance, make sure your operator is as much streamlined as possible.

   []s
   Edson

2008/9/15 Michael Zimmermann <list@incunabulum.de>

Hi Edson,

just spend some hours compiling the most recent drools version from svn
trunk and migrating my application to this version. So far, most of the
features work except
- of one issue with BaseIntClassFieldReader, see JIRA ticket 1766.
- and an incorrect import in SendIcal.java leading to a broken maven
build proces, see JIRA ticket 1767.

Edson Tirelli wrote:
> It has an interface you can implement to add operators and the parser
> accepts a quote for custom operators. It is not yet the way I want it to
> be for Drools 5 final, but it works already.
>
> For more info, look at the EvaluatorDefinition interface in Drools 5
> and its several implementations for examples.

Having looked at the EvaluatorDefinition the implementation of custom
operators seem to be straightforward now. Nice Work!

1) One question though: In drools-core each subclass of BaseEvaluator
calls the parent class as follows

public MyEvaluator()
super(ValueType.SOME_TYPE, Operator.MY_OPERATOR);

with the operators created using the private (!) constructor
Operator(id, negated) via some static variable in Operator.java.

So, well, how do I hook up a custom operator to e. g. a drools package?
There is a PackageBuilderConfiguration.addEvaluatorDefinition() method,
yet currently the only way to define the operator symbol ("==" etc) is
via a separate call to Operator.addOperatorToRegistry() first and using
the return Operator instance to create my EvaluatorDefinition. Or do I
get something wrong?

2) Also, I am wondering about the large number of nearly identical
internal classes required for each operator.Is there a specific reason
why such an operator has to be defined for each possible object type
separately?
Is this due to the way the InternalReadAccessor is called to map to the
current datatype in an operator call? And why not just call

cu, Michael

PS: Some details about my project come once I find a bit of time to
write them down coherently :-)

_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users

--
Edson Tirelli
JBoss Drools Core Development
JBoss, a division of Red Hat @ www.jboss.com