[rules-dev] TypeDeclaration plugin heirarchy

[Edson Tirelli]

    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.

* 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.

   Regarding refactoring TypeDeclaration into an interface with multiple
implementations, I think it may be a good idea. We do it all the time: make
work, generalize and refactor. :) We just need to make sure the whole
picture is addressed since the type declaration itself is just the tip of
the iceberg.

   Regarding your question on compilation, all semantic code blocks are
compiled:  for java dialect, we generate java code and compile at compile
time, for mvel dialect, it boots up in interpreted mode and JIT code as it
is needed (like java hotspot).

   The comments above represent the current design. We can changed as we see
fit. My intention is just to get you up to speed on the current design. :)

    Cheers,
      Edson

2008/8/28 Stephen Kestle <stephen.kestle at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20080828/1e3c9eee/attachment.html