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
|