I find this behaviour of jess (60b3) strange:
Jess> (deffunction lala () (bind ?a "rrrr") (printout t ?a crlf))
TRUE
Jess> (lala)
rrrr
Jess> ?a
^$%^$#^$ Throws an exception - it's ok up to now, variable ?a exists just
in lala's context
BUT:
Jess> (bind ?a "hoho") - ?a is in the global context now
"hoho"
Jess> ?a
"hoho"
Jess> (lala)
rrrr
Jess> ?a
"rrrr" - ..$#@ ?? bind changed the value of ?a in the global
context
Variable ?a is handled as a global one here, but it shouldn't, I
guess.
When I changed method setVariable of class Context, that it always changed
the values of variables in the current context only , it works as it
usually works in the most of languages.
public void setVariable(String name, Value value) throws JessException
{
//Hashtable ht = findVariable(name);
//if (ht == null)
Hashtable ht = getVariables();
ht.put(name, value);
}
Does it touch something badly?
Now about my last question. I call Jesp from a XML parser. There is a tag
(<JESS>) used for processing jess code used in these documents. The
objects (defrules, deffunctions, deftemplates, ...) which are created in
<JESS></JESS> are be localized somewhere in the XML document (section
3/subsection 2/paragraph 283/..), this information is added to a jess
module as a fact (f.i. rule X was defined in section 6), so all the
objects are described how and where they were created. To do this I need to have a
link with the parser, or with any object which knows what we is being parsed
Well, I tried to do this in more different ways (I shall not list these
now). The most elegant way (for me, maybe there are better
solutions) is to change the context of Jesp, it would work a bit like a
procedure with it's own context. So by setting a variable ?xy to the
external address of the parsing session, the procedures executed
inside the <JESS></JESS> tags could recognize where they are in the
document. Another parsing session have different context, with other value
of ?xy.
These are the changes which would help:
- Adding a method getContext(), which returns the context of Jesp.
- Calling this method instead of using
m_rete.getGlobalContext() on several places over Jesp.
Method getContext can return m_rete.getGlobalContext, so there would
not be any difference in Jesp's behaviour, but I could create a subclass
of Jesp using a different context.
The context hierarchy of jess is flat, as it doesn't have functions in
functions, it doesn't need more than one level for contexts. I recognize
that the changes in the derived Jesp class (with its own context) doesn't
work well with functions defined by this Jesp subclass, because of lines
like
Deffunction.java [136]: Context c = new
Context(context.getEngine().getGlobalContext());
these functions "jumps over" the context and work on context derived from
the global context. But it can be solved in more different ways. I am
wandering if it is useful to implement a context policy as it is common in other
languages, avoiding using always globalContext...??
Thanks
f.gy.
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
