Hey Trevor,
You got the idea about shadow facts. Just a minor comment, instead
of intercepting "set" methods and business methods, what we do is we
cache "get" methods (it means, any parameterless method with return type
!= void).
From your explanation, my understanding is that what your framework
do is conceptually identical to what we do. The implementation
difference is that we use bytecode generation instead of reflection, as
the performance of reflection is unacceptable for the core engine. Also,
you have a helper class to chain several "getters" (or extractors, in
our terminology), in order to make easy to extract nested values in an
object graph. We are developing a language to allow that transparently
but it is not ready yet.
Anyway, it do makes sense to "unify" the access methods. The thing
is, being a proprietary framework, I guess there is not much we can do
together in your side. So, questions are:
1. Can't you simply assert all objects from you business objects into
the rules engine and let extractors handle your object constraints? So,
your application would continue to use your getter framework externally
to the rules engine, but the rules engine would use the extractors
directly over your business objects. This way you also don't need to
worry about shadowing your beans. That would be the easiest way, but I
guess you can't.
2. Would you like to get involved in the development of the new language
in a way it can suit both general community needs and your specific needs?
3. Would you like to check new trunk code, and we can discuss a way to
make it flexible to accept your getters as a pluggable extension, and
then you can provide a patch for it?
Regards,
Edson
Trevor Pocock wrote:
Hallo Edson
Im not going to pretend i understand all the details about the
shadow facts, but
i think you mean there needs to be a layer between the asserted
beans and the
engine to control when changes to the beans have an effect upon
the engine, e.g. with
then
$foo.setBar(123)
...
the change to the Foo is currently immediate, but this causes problems,
so the aim is to make the change visible after the rule ends (or if
modify(foo) is called?)
A little bit about "our" getters (we have a license to use the system,
so i cant distribute everything). The reason i thought about them
looking at your extractor factory, is that they in some ways touch on
the same ideas. As far as i see, you have a set of extractor classes,
each with a method like
Object getValue(Object owner)
and the factory is responsible for creating an instance of the right
extractor class based on the type of the field being extracted (int,
double, boolean, Object)
"our" system allows you to have any number of "getter" classes which
have at the heart a similar getValue(Object owner) method. Here in a much
simplified form:
interface Getter {
Object get(Object owner);
}
interface IntegerGetter entends Getter {
Integer getValue(Owner owner);
}
interface ObjectGetter entends Getter {
Object getValue(Owner owner);
}
class Foo {
int bar;
public static IntegerGetter barGetter =
new IntegerGetterImpl(Foo.class, "bar" ..type info etc..);
}
some client {
...
Foo myFoo;
Integer bar = Foo.barGetter.getValue(myFoo);
...
}
One such Getter class allows any number of object getters to be
chained together to form a path so you can define lookups over
relationships, e.g. imagine a
class Zop {
Foo zopsFoo;
public static ObjectGetter zopGetter =
new ObjectGetterAdapter(Zop.class, "zopsFoo" ..type info etc..);
}
some client {
...
Zop myZop;
IntegerGetterChain myPath =
new GetterChain().add(Zop.zopGetter).add(Foo.barGetter);
Integer bar = myPath.getValue(myZop);
...
}
We make use of the getters in almost every level of our eclipse
rich client/app server/database application
Trevor
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
