I think [EMAIL PROTECTED] wrote:
> Hello-
>
> On Wed, 2 Aug 2000 [EMAIL PROTECTED] wrote:
> > A contest: name the Facade class?
>
> I think the refactoring is a great idea, but breaking the most common
> external uses of Rete is rather not a welcome idea.
>
> I often wished that the Rete class was just called Engine or Jess, but
> Shell also seems appropriate. What this suggests to me is that a new
> _set_ of facades be offered which provide cleaner use-case interfaces for
> engine and shell control. However, Rete should remain reserved as a
> holistic facade, at least for backwards compatibility (in which case
> documentation should strongly suggest discontinuing its use). Basically,
> instead of 'Main', leave it as 'Rete'. To me, it would be a crime to
> offload the name substitution process on all the developers using
> Rete, though deprecating a few methods is more acceptable.
I'm starting to think this too, even though it could be a bit of a
maintenence problem. I think perhaps what I might do will be to
1) Create new class Filter or PatternMatcher or some such to be what
Rete ought to be.
2) Alter Rete so that it provides the same interface it currently
does, but doesn't implement anything; instead it passes everything
along to methods in other classes. Do not mention Rete in the
documentation, at all, except in a special section on how to
transition away from it.
3) Create a new class Jess or Shell or Facade to be what Main ought to
be.
4) Alter the existing Main in a parallel way.
This way most existing code should continue to work, and there will be
a clear migration path away from the older stuff.
>
> As to giving a new name to the cleaner pattern matching class, how about
> calling it 'Filter'? (BTW, 3M has the trademark 'Filtrete' for its air
> filters.)
That's cute!
I think Rete is better suited to that which encompasses the
> filtering, i.e., including the knowledgebase, rules, pattern network and
> agenda, which agrees with the existing Rete class definition.
>
> The use of interfaces might help in the organization. For instance,
> JessEngine and JessShell interfaces might serve well to divide and conquer
> the refactorization, further abstracting how the existing Rete class is
> implemented, and offering Engine and Shell as standard implementations?
> But this certainly shouldn't be the end of it.
>
> Taking a note from the JDBC API, encapsulating the nitty gritty in a few
> MetaData (Engine/Shell) classes would allow these new interfaces to be
> well defined as a second tier abstraction. It is important to realize
> that most of these facade interfaces are probably not speed critical, so
> ease of use and abstraction should take priority. I dare say that
> refactorization should benefit _internal_ performance quite a bit.
>
> I don't suppose we'll be seeing any design proposals as UML diagrams, will
> we? (Yes, I know I'm a troublemaker.)
>
I have and do use Together/J and StructureBuilder on various
projects. Neither has an ASCII-art export option, however, and I don't
want to be sending GIFs or HTML mail on this list, so I guess it's
unlikely.
> -Dave Barnett
>
---------------------------------------------------------
Ernest Friedman-Hill
Distributed Systems Research Phone: (925) 294-2154
Sandia National Labs FAX: (925) 294-2234
Org. 8920, MS 9012 [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 (use your own address!) List problems? Notify [EMAIL PROTECTED]
---------------------------------------------------------------------
