Zack,
Thanks for the update and please, do open JIRAs for everything you found
that is not working and ping me after.
I am working on the binding with extra variables issue at the moment.
E.g.:
$x : someMap[$y]
The problem here is that Drools always used a fly weight pattern with no
additional inputs for variable bindings. This means it is not possible as of
Drools 5.3 to support that kind of variable binding. What I am doing at the
moment is implementing a more friendly error message for 5.3. For 5.4 I am
discussing it with Mark, but I think we should add support for it.
Please note that as a work around, in 5.3, you can still bind the
variable to the map ($x : someMap) and then on usage apply the key:
foo == $x[$y]
Edson
2011/10/11 zstlaw <zstlawre(a)akamai.com>
Ok finished doing some in depth testing on 5.4. I was wrong on a
few
accounts above the internal variable access to a hash still fails only in a
different way.
First off I added a few new methods to my Mailbox object just for testing :
// returns an statically defined inner enum
public FolderType getDefaultFolderType() {
return FolderType.INBOX;
}
// returns an external enum
public MailType getMailType() {
return MailType.WORK;
}
// takes a statically defined inner enum and returns an external enum
public MailType getMailTypeForFolderType(FolderType pType) {
return MailType.WORK;
}
Test I found that generally enums work much better but internal defined
instances still cause problems. Also there was some asymmetry where
FolderType.INBOX != $folderType was legal but $folderType !=
FolderType.INBOX was not.
I will start opening issues in JIRA but expect I may need to open one or
two
large issues and a lot of sub issues to keep clarity. In particular the
issue with having an assignments and a variable in the same row continues
to
be vexing (i.e. $myvar : getFoo($otherVar) always has problems evaluating
$otherVar since it wants to check it as a inner field of the return type
and
not a local variable passed to the procedure call.)
Hope some of this can get in the next build. I have some huge projects
coming up where we really want to use drools but I am having to really
simplify our data to work around some of these issues.
Thanks,
Zack
--
View this message in context:
http://drools.46999.n3.nabble.com/Map-errors-and-quirks-tp3404106p3413546...
Sent from the Drools: User forum mailing list archive at
Nabble.com.
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
--
Edson Tirelli
JBoss Drools Core Development
JBoss by Red Hat @
www.jboss.com