<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Jun 9, 2013 at 9:16 AM, Levente Uzonyi <span dir="ltr"><<a href="mailto:leves@elte.hu" target="_blank">leves@elte.hu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
I started rewriting Environments to use a different kind of dictionary, which won't get into an inconsistent state when a binding is modified. The rewrite is almost ready, but I still don't understand a few things:<br>
</blockquote><div><br></div><div style>Interesting. By modified, you mean changing the key? What's the motivation for the rewrite?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
1) Some methods use the instance variable 'references' to look up bindings, others use 'declarations'. After the rewrtie some tests don't pass, because the bindings don't get added to 'references', but they are present in 'declarations', so using the latter will make the tests pass.<br>
According to the class comment:<br>
<br>
declarations <IdentityDictionary><br>
Bindings for globals that have been declared inside me<br>
<br>
references <IdentityDictionary><br>
Bindings for globals that are used by methods compiled inside me.<br>
<br>
Which suggests that neither 'declarations', nor 'references' are good enough for lookup in case of #associationAt:, #associationAt:ifAbsent: or #associationOrUndeclaredAt:, #at:, #at:if*:, etc.<br></blockquote>
<div><br></div><div style>This is probably the most difficult part of the transition. Until now, you could make the assumption that all bindings are visible everywhere. So clever code could rifle through the SystemDictionary and adapt it's behaviour to what it finds, or even make modifications. But now code that operates at that level has to make the distinction between declarations and references. This is why I'd like to create separate protocols for this sort of thing. Sending #bindingOf: clearly asks for the reference—the binding that a method compiled in the environment would use. We could use #declarationOf: or some such to mean the binding of a class declared in the environment. Using #associationAt: bypasses any abstraction messes directly with the implementation, which is now changing.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
There either need to be a dictionary which contains all the bindings visible from the Environment, or the class comment is wrong and 'declarations' is exactly that. In the latter case 'references' seems to be superfluous to me.<br>
</blockquote><div><br></div><div style>Both are needed. Let's imagine the case where we create an empty environment and then file-in a package containing classes and methods. When a class is built and installed in to the environment, a new binding is created and added to declarations. (So "declarations" contains all the classes that have been declared inside the environment. Ok, syntactically it's not really a declaration, this is the most descriptive name I could find… certainly better than "contents".) </div>
<div style><br></div><div style>When a method is compiled, we first look in "references" for the required bindings. If we find one, great, we use that. But since this is a brand new environment, references is empty. So we have to import the binding. The "imports" variable contains a list of rules for where we should look for the binding. One of the rules will look in "declarations" and find the binding there. Now that we have the binding, it gets added to references so that we'll get consistent bindings for all the methods compiled in the environment, and returned to the compiler to be added the method's literal frame. </div>
<div style><br></div><div style>Make sense? We need to keep separate the bindings that are *created* in the environment from the bindings that are *used* in the environment. </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2) The only way for a binding to get into 'references' is to get into 'imports' first and get copied to 'references' in #bindingOf:ifAbsent:. But how does a newly compiled class's binding get into 'imports'?<br>
</blockquote><div><br></div><div style>Imports doesn't contain bindings. It contains rules about where to go looking for bindings.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
And why does that happen? The class comments suggests that only referenced (used by some methods) classes' bindings get into 'references', but new classes are not referenced by any method.<br></blockquote><div>
<br></div><div style>It happens lazily. When compiled method refers to a class, the binding gets copied into references. Until that happens, the binding is only in declarations.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
3) There are multiple classes being used for bindings including: ClassBinding, Global, Alias and Association (all bindings created in Undeclared are Associations, since it's a simple IdentityDictionary).<br>
The type of these bindings can change. Sometimes a class is created from a global (Global->Class) or a class gets declared (Association->Class), etc<br>
In these cases the class of the bindings should follow these changes. But AFAIK that's not happening now, and those would require a #becomeForward: send, which is rather slow. We could address these if the type of the binding would be stored in an instance variable, but that's a bit less flexible. Any ideas what to do with these?<br>
</blockquote><div><br></div><div style>I don't think speed is an issue here—it doesn't happen very often, right? I had thought that we no longer need a full #becomeForward: when converting bindings, and #asBinding: is sufficient. I could be wrong though. What problems are you seeing?</div>
<div style><br></div><div style>Colin</div></div></div></div>