commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giorgio Gallo <giorg...@overlord.it>
Subject [JELLY] scopes and JellyContext.isExport(), plus a bunch of questions
Date Tue, 19 Apr 2005 21:29:41 GMT

I am wotking on adding "a Scope class to make it easier to plugin custom
scopes" (as per the TODO list).

I have tought that taking the variable-handling stuff out of
JellyCopntext could be a Good Thing, since that class seems to already
have a whole bunch of responsibilities, so I started to code a
replacement for that part of JellyContext instead of a simple "holder"
scope with copyToContext(JellyContext) and copyFromContext(JellyScope)
methods.

While doing so I bumped into JellyContext.isExport()... :)

Right now the behaviour of a jelly context with export=true is to live
as a parasitic of its parent and to define its own variables into the
parent scope (context).

The behaviour is now such as:

1)
//parent scope
// no 'foo' defined here
{
	// child scope
	String foo = "bar";
}
// use a in parent scope
System.out.println(foo);

2)
//parent scope
String foo = "asdf";
{
	// child scope
	String foo = "bar";
}
// use a in parent scope
System.out.println(foo);

would both output "bar"

Is this intended behaviour, or was the exporting stuff intended only to
allow for stuff like

//parent scope
String foo = "bar";
{
	foo = "asdf";
}
System.out.println(foo);

to output "asdf"? (or to prevent it from doing so if export=false)

========

BTW:

a)
Would features such as:
- knowing whether a certain variable (variable name) is visible from a
given scope
- knowing if a certain variable has been initialized
- checking for variable names to be "valid" (eg: w/o whitespace,
non-empty, non-null...)
be welcome in a scope implementation?

b)
Would introducing a variable (meaning "reference") class be welcome?
IMO it could be nicer to have persistent variables instead of (or in
addition to) persistent scopes.

Thanks,
	Giorgio




---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message