<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Edson Tirelli wrote:
<blockquote
cite="mid:e6dd5ba30802201439j1a28b31y8a9ad135ddadd0a6@mail.gmail.com"
type="cite"><br>
Godmar,<br>
<br>
Ok, now I understood what you mean. This ability to use Maps as a
"special" type of facts requires the implementation of what we call
"pluggable fact types". It is something we wanted to have for ages, but
it is not implemented yet. Unfortunately it is not as "easy" as it may
appear, but definitively it is a must have for the future, specially as
we move to the ontology space. <br>
You are right to think that this will give us another level of
expressive power. Among several other advantages, it would allow the
the user instead of writing patterns like:<br>
<br>
Map( this.factType == "SomeFactType", ... )<br>
<br>
Where "factType" is a key in the Map, to simply write rules:<br>
<br>
SomeFactType( ... )<br>
<br>
More than that, once we have such feature, we can directly use any
structure mappable into a Java class as a fact, like
Grrovy/Jython/Whatever beans, CSV files, XML documents, etc.<br>
So, it is REALLY powerful and really cool! <br>
<br>
Our only limitation is indeed "(wo)man power"... :) <br>
Seriously speaking, we already have pluggable dialects, pluggable
evaluators and an "almost pluggable" extractor framework. All of them
are pre-reqs for the pluggable fact types, but we did not reached that
point yet.<br>
<br>
Talking about the project, the team is now committed to deliver
support to CEP applications (including temporal reasoning and stream
management), support to higher levels of ruleflow and process modeling,
improving the whole BRMS and repository tools, plus we have Master
Degree and PhD students working on Machine Learning, Decision Trees,
Uncertainty Reasoning, Temporal Reasoning and Rulebase Static Analysis.
<br>
As you can see there is a LOT on our plate, so if anyone wants to
step up and help us accelerate the development of pluggable fact types,
it is more than welcome.<br>
</blockquote>
The engine is already mostly model independant, via our use of
ObjectType and Extractor interfaces. Its now a matter of making that
design clean and pluggable. I'm hoping that once we remove shadow
proxies when I merge my branch, for 5.0, having pluggable extractors
will be even easier.<br>
<blockquote
cite="mid:e6dd5ba30802201439j1a28b31y8a9ad135ddadd0a6@mail.gmail.com"
type="cite"><br>
ANYONE up to the task? :)<br>
<br>
Regarding your question about the removal of shadow fact, yes, it is
scheduled for the next major release in a few months time. Although, it
is import to remember that you can already disable shadow facts, just
by following some requirements. I will write another e-mail about that.<br>
<br>
[]s<br>
Edson<br>
<br>
<br>
<div><span class="gmail_quote">2008/2/20, Godmar Back <<a
moz-do-not-send="true" href="mailto:godmar@gmail.com">godmar@gmail.com</a>>:</span>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I
think that you *should* treat facts that implement java.util.Map<br>
differently from other facts.<br>
Ignore their concrete class and don't worry about applying your<br>
shadowing algorithm.<br>
Then, treat them as if they were beans with getXYZ() methods for each<br>
key "XYZ" they contain.<br>
<br>
Your reply indicates that you haven't even considered this design. I<br>
wonder why not? (It seemed so natural to me that I assumed it's what<br>
Drools *must* do. Especially considering the fact that Drools's chosen<br>
scripting language, MVEL, supports accesses to maps using a special,<br>
javascript-like syntax that allows you to verify that accesses are<br>
side-effect free.)<br>
<br>
<br>
On Wed, Feb 20, 2008 at 4:11 PM, Edson Tirelli <<a
moz-do-not-send="true" href="mailto:tirelli@post.com">tirelli@post.com</a>>
wrote:<br>
><br>
> A blog I wrote a long time ago about dynamically generated
beans:<br>
><br>
> <a moz-do-not-send="true"
href="http://blog.athico.com/2006/12/dynamically-generated-class-beans-as.html">http://blog.athico.com/2006/12/dynamically-generated-class-beans-as.html</a><br>
><br>
<br>
<br>
I'm aware that I can generate beans - dynamically or statically, but<br>
that is exactly the hassle I had hoped to avoid. (And, quite frankly,<br>
it's not something I should have to go through when using a framework<br>
such as Drools.)<br>
<br>
Will the issue disappear in a future, shadowless version of your<br>
engine? To what degree will this version depend on facts being<br>
conforming Java beans?<br>
<br>
<br>
- Godmar<br>
_______________________________________________<br>
rules-users mailing list<br>
<a moz-do-not-send="true" href="mailto:rules-users@lists.jboss.org">rules-users@lists.jboss.org</a><br>
<a moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/rules-users">https://lists.jboss.org/mailman/listinfo/rules-users</a><br>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
Edson Tirelli<br>
JBoss Drools Core Development<br>
Office: +55 11 3529-6000<br>
Mobile: +55 11 9287-5646<br>
JBoss, a division of Red Hat @ <a moz-do-not-send="true"
href="http://www.jboss.com">www.jboss.com</a>
<pre wrap="">
<hr size="4" width="90%">
_______________________________________________
rules-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:rules-users@lists.jboss.org">rules-users@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/rules-users">https://lists.jboss.org/mailman/listinfo/rules-users</a>
</pre>
</blockquote>
<br>
</body>
</html>