Hi Dave,
Hmm. Hadn't thought of this until you mentioned it. Turns out my
implementation needed only a bit of polishing for this to pop out for
free.
It's immediately obvious to me why inheriting a defclass from a
deftemplate is useful: you can make Beans appear to be subclasses of
make-believe common ancestor classes without writing any Java code -
i.e., the example I gave with the 'machine' class can be done with a
deftemplate instead of a defclass; then Pump and Tank no longer need
to have a common subclass, but you can group them together for the
sake of pattern matching. It's very neat, actually - if the Beans have
property names in common, then a common deftemplate 'superclass' can
let you match on that shared property, even if the Beans are otherwise
unrelated. I've modified things so that it behaves this way if the
superclass is a defclass, as well.
In the other direction, I'm not sure it'd be as useful - the subclass
deftemplates would lose the magical Java-connectedness of their parent
defclass, which could be confusing.
Hmm. Maybe, though, I can think of a shceme for creating hybrid
objects which effectively let you add Jess-only properties to a
defclassed Bean instance. Would that be useful or interesting?
I think Dave Carlson wrote:
>
> Outstanding! How about another twist, where a deftemplate inherits from a
> defclass, e.g.
>
> (defclass machine jess.examples.pumps.Machine)
> (defclass pump extends machine jess.examples.pumps.Pump)
> (deftemplate bigpump extends pump (slot foo))
>
> I'm thinking about a non-Java programmer who is writing rules. They are
> provided with a set of Java objects, but need to create a local subclass for
> use within their rulebase.
>
> -- Dave
>
> At 02:28 PM 9/1/98 -0700, you wrote:
> >Hi Folks,
> >
> >Just sharing a little bit of info about another Jess 4.2 feature:
> >you'll be able to define inheritance relationships between
> >deftemplates and between defclasses. Alan Davis was asking about this a
> >little while ago, and I just had an insight yesterday about how
> >to do this efficiently.
> >
> >Anyway, so what this looks like is this:
> >
> >(deftemplate t1 (slot A) (slot B) (slot C))
> >(deftemplate t2 extends t1 (slot D) (slot E))
> >(deftemplate t3 extends t1 (slot F) (slot G))
> >
> >Now you can write rules which match on patterns of type t1, t2, or
> >t3. t2 has slots A,B,C,D,E, and t3 has A,B,C,F,G. Furthermore, rules
> >written to match patterns of type t1 will also match t2 and t3; rules
> >that match t2 or t3 patterns won't match the other, or t1.
> >
> >Similarly, with defclasses. I modified my 'pumps' example Beans such
> >that both Tank and Pump inherit from a new class Machine, with one
> >property (name). Then you can write
> >
> >(defclass machine jess.examples.pumps.Machine)
> >(defclass pump extends machine jess.examples.pumps.Pump)
> >(defclass tank extends machine jess.examples.pumps.Tank)
> >
> >and 'machine' rules will match either 'tank' or 'pump' patterns.
> >
> >Any comments on syntax, ideas for extensions, or subtleties, let me
> >know. I considered using 'is-a' as COOL does instead of 'extends' -
> >any opinions one way or the other?
> >
---------------------------------------------------------
Ernest Friedman-Hill
Distributed Systems Research Phone: (510) 294-2154
Sandia National Labs FAX: (510) 294-2234
Org. 8920, MS 9214 [EMAIL PROTECTED]
PO Box 969 http://herzberg.ca.sandia.gov
Livermore, CA 94550
---------------------------------------------------------------------
To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]'
in the BODY of a message to [EMAIL PROTECTED], NOT to the
list. List problems? Notify [EMAIL PROTECTED]
---------------------------------------------------------------------
