----- Original Message ----- 
From: "Colin Putney" <cputney at wiresong.ca>
To: "The general-purpose Squeak developers list"
<squeak-dev at lists.squeakfoundation.org>
Sent: Saturday, November 20, 2004 4:41 PM
Subject: Re: bindingOf question?


>Yes, but what if you aren't using a subclass of Behavior? One might
>want to create instances of Behavior its self. In that case you'd want
>the behavior to have a working #bindingOf: so that you can compile
>methods for it.

True. I didn't think of that.
The current situation is that an instance of Behavior whose superclass is
nil will 'effectively' have no Environment.
But methods can still be compiled for it, they just can't reference any
globals.

On the other hand, if its superclass is not nil, then methods can be
compiled for it that reference globals (in the superclass's environment).

If the implementation of Behavior>>bindingOf: is changed to look in 'self
environment' first,
 then globals (in the Smalltalk environment) can be referenced from Behavior
instances that have a nil superclass.
And this seems attractive.

But, suppose that the superclass is NOT nil and the superclass's environment
is NOT Smalltalk.
Then, intuitively, I would assume that the Behavior instance would resolve
using its superclass's environment (which may, or may not, be Smalltalk).

So perhaps we should have something like this....

Behavior>>bindingOf: varName
| binding |
^ superclass
     ifNil: [self environment bindingOf: varName]
     ifNotNil: [superclass bindingOf: varName]

Or it might be better still to allow the environment for a Behavior instance
to be specified - by moving the environment instance var into Behavior from
Class.

Cheers,
Andy











---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.792 / Virus Database: 536 - Release Date: 10/11/2004