bindingOf question?

stéphane ducasse ducasse at iam.unibe.ch
Sun Nov 21 22:34:54 UTC 2004


>
>> 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.

Yes I have a fix for having anonymous classes so that you can do a 
simple
instance based methods (but no state change). I should resend it.

> The current situation is that an instance of Behavior whose superclass 
> is
> nil will 'effectively' have no Environment.

Strange because any class lives in an environment. So may be 
environment should be defined
on Behavior (I have to check that).

> 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.

Yes this is the solution from my point of view.
But adding an instance variable to Behavior seems not possible :(

Stef




More information about the Squeak-dev mailing list