Yeah, I also already noticed about these nested nested nested policies...
All this is far from obvious and the comments do not help ;)

Still on the same subject there is also this previous analysis in
http://source.squeak.org/inbox/Kernel-nice.798.diff which explains how you
can have access to the environment of your superclass... I don't know if it
is still true, but for me, the fact that I couldn't correct this was not a
sign of good health.

2014-10-31 2:10 GMT+01:00 Chris Muller <ma.chris.m at gmail.com>:

> On Thu, Oct 30, 2014 at 5:28 PM, Levente Uzonyi <leves at elte.hu> wrote:
> > On Thu, 30 Oct 2014, Chris Muller wrote:
> >
> >> Thanks guys, those both helped.  After defining X I found I could do a
> >> "Smalltalk importSelf" to get it copied into the 'bindings'
> >> Dictionary.
> >
> >
> > #importSelf is not what you want do, because that'll add the same policy
> to
> > your environment again.
>
> Oh wow, and it even will allow duplicates..(!?)  I didn't even notice
> that because I was just interested in the second part of that method.
>
> I was just operating as a Smalltalker; backtracing what was causing my
> #X lookup problem, and found it was because it wasn't in 'bindings'.
> So I browsed who ever adds anything into 'bindings'?  Only #importSelf
> and #showBinding:.  So to get the "side-effect" I wanted, I
> inadvertently also added a second BindingPolicy.  I manually removed
> the duplicate BindingPolicy, thanks for the heads-up.
>
> I think Squeak's frameworks should be implemented in a way that caters
> to its own IDE, so Smalltalker's can figure things out by those normal
> tracing activities (senders, references, implementors).  #importSelf
> seems like a not-so-good method.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20141031/4c44f360/attachment.htm