Interesting question. This is not supported right now, but I see no reason (besides being a really technical, not business related constraint) why we shouldn't support it. Just for the sake of exploring the issue, I played a bit with it and realized this is probably a limitation in our QualifiedIdentifierRestriction. There are work arounds, but I don't see any advantage in them compared to the eval. For instance, something like this will work: position : Position(option : instrument, $oc : option.class ) Class( name == "some.package.OptionInstrument" ) from $oc Or, in case you actually assert an OptionInstrument class into the working memory: $oc : Class( name == "some.package.OptionInstrument" ) position : Position(option : instrument, option.class == $oc ) So, for now, probably best to use the eval (as bellow), and if you may, open a feature request for use to properly support it in the future. position : Position(option : instrument, eval( option instanceof OptionInstrument ) ) []s Edson 2008/5/23 Barry Kaplan <groups1(a)memelet.com&gt;: -- 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

Interesting. I had never tried it without the ".class" static field in the class name. I need to investigate this a further but I think what is happening behind the scenes is that since you are using nested accessors (option.class), it is getting transparently re-written into an inline eval(). This should not be a big deal, since you don't have (I guess) too many classes and indexing/hashing would not help you that much either. So I guess performance is probably the same, but as you said, more readable. Question: what is the actual type of your "option" field? I mean, what class does getOption() returns? Object? []s Edson 2008/5/24 Barry Kaplan <groups1(a)memelet.com&gt;: -- 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