<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Apr 2, 2013 at 6:45 AM, Frank Shearar <span dir="ltr">&lt;<a href="mailto:frank.shearar@gmail.com" target="_blank">frank.shearar@gmail.com</a>&gt;</span> wrote:<br>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"> </div></div>uSo it _looks_ like Environments has a slight case of split brain: the<br>

contents and bindings instvars seem to do the same job (inspecting<br>
&quot;Environment default&quot; and looking at the contents of contents and<br>
bindings), and it looks like we&#39;re moving things over to bindings<br>
(#assocationAt: pulls stuff out of contents, while<br>
#associationOrUndeclaredAt: is more recent, and pulls stuff out of<br>
bindings. #migrate copies contents&#39; contents into bindings).<br>
<br>
Does that sound like a fair assessment? If so, I suspect that we<br>
simply haven&#39;t pushed the migration far enough yet.<br></blockquote><div><br></div><div>Sort of. </div><div><br></div><div>The &#39;contents&#39; dictionary is for classes and globals that are declared within the environment. The &#39;bindings&#39; dictionary is for bindings that are referenced from methods compiled within the environment. So when you create a class, it goes into &#39;contents&#39;, and when you refer to the class in a method, that binding gets copied (or aliased) into &#39;bindings&#39;, possibly of another environment.</div>
<div><br></div><div>Colin</div></div></div></div>