Re: calling object context

On Sat, Jun 19, 2004 at 02:12:46PM -0700, Chris Greener wrote:
> I'm really stuck on this one. Please help.

I've been trying to come up with a quick fix for you and I have something
below, but I'm guessing there may be a better way to accomplish what you want
in 1.3+.  Can you tell us a little more about how you use this?  

There is no explicit syntax for polymorphism in bsh scripted objects yet...
but there are a couple of low level tools available.  (Specifically you can set
the parent of a namespace and you can switch into an arbitrary namespace at any
time).

> outer() {
> 	this.n = "outer";
> 
> 	inner() {
> 		this.n = "inner";
> 
> 		return this;
> 	}
> 
> 	name() {
> 		print( this.caller.n );
> 	}
> 
> 	return this;
> }
> 
> inner = outer().inner();
> inner.name();

Ok, so the difficult part about replicating the old broken behavior is that the
value of 'inner' in the method invocation inner.name() is not really available
after it's resolved by the interpreter.  The "call stack" that bsh maintains
internally holds all of the scopes of a chain of method calls.  In this case
the global scope is the starting point and the name() method scope is pushed
after entering that method.

However if you are able to put simple delegate methods into your inner() object
for each of the methods in outer() we have a way to get back to that context at
runtime... using this.caller.

  outer() {
          this.n = "outer";

          nameCommand() { print(this.caller.n); } // impl
  
          inner() {
                  this.n = "inner";
  
                  name() { nameCommand(); } // delegate

                  return this;
          }

          name() { nameCommand(); } // delegate

          return this;
  }

  outer = outer();
  inner = outer.inner();
  outer.name(); // prints "outer"
  inner.name(); // prints "inner"

Note that this doesn't really depend on the inner/outer relationship.  You
could move nameCommand() outside of both of them and it would still work.
So, if you can go further and restructure your code a bit I think we can clean
it up by removing the inner/outer relationship and simply putting a set of
"commands" (base behavior) into an object and then finding a way to import that
behavior... using setParent() perhaps.

Let me know if this helps...  Sorry for the trouble.


Pat


-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND