still struggling to see what's wrong with FactTemplate. It seems
relatively
valid. Why couldn't it be finished?
Maybe I was not clear on that. FactTemplate is not bad. It is just not
finished. We have it because we both wanted something equivalent to what
clips/jess have and as a proof that the system can be extended to support
multiple format types. Since we could not mantain it, we never promoted it
to a official feature. There are limitations of course, but nothing that
could not be worked out given resources and time.
Finally, please note that at the same time that we proved it is possible to
have multiple underlying formats, it is not completely plug&play. Since the
implementation is not finished, there is quite a lot of stuff to do yet in
the internals. We will of course suport anyone that decides to undertake the
task. :)
[]s
Edson
2008/8/28 Stephen Kestle <stephen.kestle(a)orionhealth.com>
Edson Tirelli wrote:
Hi Stephen,
Nice job inspecting our code base.
The complete type abstraction layer in Drools is composed by several
interfaces and its corresponding implementations.
* TypeDeclaration is just that: a stateless type representation for
describing Facts. It is not supposed to know how to actually read fact
value, attributes, etc. It is used at compilation and runtime to read
metainformation about a fact and is not tied to any particular fact
instance.
Except that it is tied in particular to FactTemplate and classes. It
should expose the required metadata completely.
* To handle a Type, i.e., evaluate if a type matches a pattern and
manipulate the type at compile and runtime, we have an ObjectType interface.
That interface, today, has 2 implementations: ClassObjectType (for POJO) and
FactTemplateObjectType (for templates).
* To read the internals of a type we have the ReadAccessor and
WriteAccessor interfaces. These interface implementations are lazyly
bytecode generated for extremely fast access and fact manipulation at
runtime. So, in your example, there would be an AgeReadAccessor to do this:
TypeDeclaration.execute("getAge"). TypeDeclaration should only interact with
the compiler, not the actual facts.
Ok - so there's sneaky compilation going on everywhere. So reflection is
not used at all (at least at runtime).
Also, There is not FactTemplateWriteAccessor, so we cannot set fields,
except by using Fact.setFieldValue(). If there was a write accessor (and a
FactField implementation and plugging for FactTemplate) then it would be
complete?
I'm starting to get my head around the classes and structure, but I'm still
struggling to see what's wrong with FactTemplate. It seems relatively
valid. Why couldn't it be finished?
Also, is there any way of actually using TypeDeclarations outside of a
package script or javabean? e.g. there's no simple way of getting existing
objects into a template without writing a bit of reflection...
Thanks
2008/8/28 Stephen Kestle <stephen.kestle(a)orionhealth.com>
>
>
> Edson Tirelli wrote:
>
> There are a few issues on how templates were implemented. The main one,
> and probably the main reason we did not extended the functionality to
> support any underlying fact format, is the syntax support on semantic code
> blocks. I.e. dialect support, specially on consequences.
>
> Yes, I thought $person.getFieldValue("age") was a bit annoying...
>
> But the more I look into the code and interfaces around FactTemplate, the
> more I like it's approach and it's fit for ontological (dynamic
> model/schema) data models.
>
> 1. MVEL etc needs to reflect on methods to give the dialect support to
> POJOs
> 2. To make an dynamic model fit to OO, TypeDeclarations would need to
> be able to generate interfaces, an a proxy mechanism would be needed for the
> map-backed model - this just seems too retarded
> 3. Surely TypeDeclaration should be an interface with methods to gain
> method information and types etc. PojoTypeDeclaration would implement this
> using the reflective model as current. TemplateTypeDeclaration would use
> the FactTemplate to do it (if it was being continued). This way maximum
> pluggability is maintained.
> 4. Isn't this what FactTemplate does? I see the problem is that
> FactTemplate was an add-on, instead of a super set / *the* way of accessing
> fact type information.
> 5. Is this idea awesome? Calling TypeDeclaration.execute("getAge")
> does not seem any different to how it is now - how "compiled" are these
> rules? If they are byte-compiled, then that optimisation could be done for
> PojoTypeDeclaration.
>
> How correct am I on these points?
>
> Cheers
>
> Stephen
>
--
Edson Tirelli
JBoss Drools Core Development
JBoss, a division of Red Hat @
www.jboss.com
------------------------------
_______________________________________________
rules-dev mailing
listrules-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-dev
co-operation.
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev
--
Edson Tirelli
JBoss Drools Core Development
JBoss, a division of Red Hat @