Alan Moore wrote:
>
> see comments below:
>
> > -----Original Message-----
> > From: Alessandro Saporiti
> > [mailto:[EMAIL PROTECTED]]
> > Sent: Wednesday, February 09, 2000 6:07 AM
> > To: [EMAIL PROTECTED]
> > Subject: JESS: Store and fetch objects
> >
> >
> > Hi ,
> > as you can argue I'm dealing with a problem about object handling.
> > I want to pass objects from Java to Jess and viceversa. So I
> > use store and
> > fetch.
> > Both store() and fetch() allow to handle one object at a time using a
> > specific name for each object.
> > The problem is that the number of object to be passed in and
> > out (Java -
> > Jess) is not fixed.
>
> [alan]
> You can create a "holder" HashMap or other collection and populate it with
> your objects. Pass this into jess and you are on your way. I found the
> easiest way to pass object to jess is to:
>
> Userfunction fun = m_rete.findUserfunction("your-deffunction-name-here");
> if ( fun == null )
> {
> return false;
> }
>
> // Create your arg values
> Value arg1 = new Value( myArg1 );
> Value arg2 = new Value( myArg2 );
>
> // Create your "callstack"
> ValueVector vv = new ValueVector();
> vv.add( new Value( "your-deffunction-name-here" ) ); // see BTW below
> vv.add( arg1 );
> vv.add( arg2 );
> // NOTE: you may want to create a collection to pass in as a single arg...
>
> // call the deffunction
> fun.call( vv, m_rete.getGlobalContext() );
>
> BTW - I still don't know why the first callstack value (the deffunction
> name) is required since we got this function from findUserfunction() - oh
> well.
>
> See the following references:
>
> http://herzberg.ca.sandia.gov/jess/docs/api/jess/Rete.html#findUserfunction(
> java.lang.String)
>
> > So I can't determine the name every object refers to.
> > Now I use one only name to store all the objects. But I can't
> > do the same
> > for fetching them, because the object returned (fetched) is
> > always the last
> > stored (of course: I use one only name for all !! ).
>
> [alan]
> I ran into a similar problem where I tried to definstance the *same* object
> twice under *different* names. The upshot is that only *one* instance of an
> object can used for *pattern matching* regardless of its alias (you can
> however have many instances of object one or more facts as mentioned in the
> discussion below.)
>
> Note - be carefull because sometimes you may be given two object references
> to the same object. This is the case with the Apache JServ - the
> HttpServletRequest and HttpServletResponse passed into your service method
> are actually just interfaces implemented by the same object (it is actually
> a JServConnectionRequestResponseSomthingOrOther.)
>
> See the manual for more information:
>
> http://herzberg.ca.sandia.gov/jess/docs/functions.html#definstance
>
> Also, for more info on why things are the way they are (ideas on how to
> resolve these issues are welcome!!!):
>
> *** from private email exchange with author ***
>
> Hi Alan,
>
> Thanks for figuring out what was going wrong. I gave this some
> thought, as to whether Jess should allow things to be "doubly
> definstanced" this way. I tought of a few minor difficulties and a few
> serious performance indications for doing so.
>
> One thing is the "undefinstance" command. Its syntax would have to
> change: you'd have to say "(undefinstance ?x as TypeName)" or
> something like that. This might be difficult for the user in some
> cases; they might not be tracking which definstances are of which
> defclass, so they'd need to keep a table of some kind.
>
> Another is what happens when Jess gets a PropertyChangeEvent for a
> definstanced object. Right now, it can simply look up the class in a
> hashtable, retrieve the relevant fact, modify it, and reassert it. If
> there could be multiple facts, Jess would need a more complex data
> structure (this is trivial) but would need to make some difficult
> choices. Since it couldn't know which defclass the Bean was modified
> through, it would either have to sort through all of the facts looking
> for changed slots (lots of messy, expensive code on every property
> change) or it would have to simply change them all (which would cause
> unexpected effects if the user doesn't know that two definstances
> actually refer to the same object, as was the case here.)
>
> In its current state, Jess does return an error for the second
> definstance - you're showing the code below, and you can see the
> <Fact--1> in the output (fact-ID minus 1). If this were a possiblity,
> you could of course test for this return value in Jess code.
unsubscribe jess-users [EMAIL PROTECTED]
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
