<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jan 1, 2014 at 4:31 PM, Frank Shearar <span dir="ltr"><<a href="mailto:frank.shearar@gmail.com" target="_blank">frank.shearar@gmail.com</a>></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">
> Item was added:<br>
> + ----- Method: BindingPolicyTest>>testAddHonorsEnvironment (in category 'tests') -----<br>
> + testAddHonorsEnvironment<br>
> + | binding other |<br>
> + other := Environment withName: #other.<br>
> + policy := self bindingPolicyWithNamePolicy: AllNamePolicy new.<br>
> + binding := #Griffle => value.<br>
> + policy binding: binding addedTo: other notify: self.<br>
> + self assert: notified = nil!<br>
<br>
</div></div>I think I've established my reputation as a loud lover of<br>
#assert:equals: :) Just sayin'.<br></blockquote><div><br></div><div>I'm too used to the debugger, I guess. Using #assert:equals: feels like JUnit's work around for the fact that you get an error message, not a debugger when the test fails. But now that we have automated testing, we need the work around too!</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
What I often do is set these kinds of variables - variables that show<br>
that some side effect took place - to some obviously wrong value. In<br>
this case, you could set notifier := #notCalled in the #setUp.<br></blockquote><div><br></div><div>Ah, nice. I'll make that tweak.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I can't figure out what this test _does_ though: when you say that add<br>
honours Environment, you mean that it only adds the binding if the<br>
addedTo: environment matches the policy's environment, and we know<br>
this because the notifier isn't called?</blockquote><div><br></div><div>Yes, exactly. The policy responds to changes in a particular environment, and directs another environment to take action in response. So imports react to events in the "upstream" environment, and tell the local environment to add or remove bindings in to stay in sync. Exports react to changes in *this* environment, and notify the "downstream" environments about them. </div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
> Item was added:<br>
> + ----- Method: BindingPolicyTest>>testRemoveHonorsEnvironment (in category 'tests') -----<br>
> + testRemoveHonorsEnvironment<br>
> + | binding other |<br>
> + other := Environment withName: #other.<br>
> + policy := self bindingPolicyWithNamePolicy: AllNamePolicy new.<br>
> + binding := #Griffle => value.<br>
> + policy binding: binding removedFrom: other notify: self.<br>
> + self assert: notified = nil!<br>
<br>
</div>Same thing as #testAddHonorsEnvironment?<br></blockquote><div><br></div><div>Yes, but for a binding removed, rather than added.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">> Item was changed:<br>
> ----- Method: EnvironmentTest>>testImportAddingPrefixResolvesUndeclared (in category 'import tests') -----<br>
> testImportAddingPrefixResolvesUndeclared<br>
> | binding foreign |<br>
> foreign := Environment withName: #Foreign.<br>
> foreign exportSelf.<br>
> + foreign bind: #Griffle to: value.<br>
> + binding := env undeclare: #XXGriffle.<br>
<br>
</div>I like this. Nice & explicit language.</blockquote><div><br></div><div>I'm hoping to build up a simple protocol for this stuff, so we can't replace all the dictionary manipulation that's scattered around the image with more semantically explicit messages. See, for example #declarationOf:.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">
> Item was changed:<br>
> ----- Method: EnvironmentTest>>testImportAliases (in category 'import tests') -----<br>
> testImportAliases<br>
> | foreign v2 v3 |<br>
> foreign := Environment withName: #Foreign.<br>
> foreign exportSelf.<br>
> foreign at: #Griffle put: value.<br>
> foreign at: #Nurp put: (v2 := Object new).<br>
> foreign at: #Ziffy put: (v3 := Object new).<br>
<br>
</div>Shouldn't these be #bind:to: now?<br></blockquote><div><br></div><div>Yeah... missed updating them. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
> + env from: foreign import: {#Nurp -> #Plonk. #Ziffy -> #Wiffy}.<br>
> - env from: foreign import: {#Plonk -> #Nurp. #Wiffy -> #Ziffy}.<br>
<br>
</div>I find this hard to understand. So the Array of Associations looks<br>
like it says "when you see Ziffy, interpret that as if you saw Wiffy",<br>
or "map Ziffy to Wiffy". Oh. It says "when you import foreign, map<br>
foreign's Ziffy to env's (new) Wiffy. OK, that makes sense.</blockquote><div><br></div><div>I think I had it backwards in the previous version, because the lazy lookups make all the name transformations happen the wrong way around. It should match the simple version of the import. So this:</div>
<div><br></div><div>env from: foreign import: #Wiffy</div><div><br></div><div>means pretty much what it says, "import #Wiffy from foreign". The renaming version is (now) similar:</div><div><br></div><div>env from: foreign import: #Wiffy -> #Ziffy</div>
<div><br></div><div>meaning, "import foreign's #Wiffy, but rename it to #Ziffy"</div><div><br></div><div>I guess that's the opposite of what you concluded.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">
> ----- Method: EnvironmentTest>>testImportWritable (in category 'import tests') -----<br>
> testImportWritable<br>
> | foreign binding |<br>
> foreign := Environment withName: #Foreign.<br>
> foreign exportSelf.<br>
> + foreign bind: #Griffle to: 'v1'.<br>
> + env from: foreign import: #Griffle -> #Plonk.<br>
> - foreign at: #Griffle put: 'v1'.<br>
> - env from: foreign import: #Plonk -> #Griffle.<br>
> binding := env bindingOf: #Plonk.<br>
> binding value: 'v2'.<br>
> + self assert: (foreign declarationOf: #Griffle) value = 'v2' !<br>
> - self assert: (foreign bindingOf: #Griffle) value == 'v2' !<br>
<br>
</div></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I realise this is existing behaviour, but I'm not so keen on<br>
sub-environments being able to tinker with parent environments'<br>
bindings. What's the use case here? It means an Environment can't be<br>
used as a sandbox.</blockquote><div><br></div><div>This is really for Globals. It just ensures that all environments that share a global will see the same value, regardless of what it's called. </div><div> </div><div>
<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
> Item was added:<br>
> + ----- Method: EnvironmentTest>>testUndeclare (in category 'binding tests') -----<br>
> + testUndeclare<br>
> + | one two |<br>
> + one := env undeclare: #Griffle.<br>
> + two := env bindingOf: #Griffle.<br>
> + self assert: one == two.<br>
> + self assert: one class == Global!<br>
<br>
</div>Ah. This shows that you can always add new undeclared stuff to an<br>
environment. The name of the test didn't tell me that :/. </blockquote><div><br></div><div>Well, it mostly tests that #undeclare: exists and works as expected: it answers the same binding the subsequent calls to #bindingOf will answer. </div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Also, is it<br>
part of the API that one value isNil?</blockquote><div><br></div><div>It should be, yeah. Oversight on my part. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
</div>Minor nit: one of these tests says "BecomeSomething" and the other<br>
says "BecomesSomething".</blockquote><div><br></div><div>Will fix. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
> Item was changed:<br>
> + ----- Method: MCClassDefinitionTest>>testLoadAndUnload (in category 'as yet unclassified') -----<br>
<br>
</div>So all this noise in the Monticello tests is because there are two<br>
Tests-fbs.280 - one in trunk, and one in the inbox. Fun times. The one<br>
in the inbox changes the MC tests to load definitions into an<br>
Environment that's then thrown away after the test runs. This avoids<br>
MC mucking around with global state.<br></blockquote><div><br></div><div>Ugh, sorry about that. Didn't notice the extra changes. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The changes have been sitting in the Inbox for a week, but given<br>
Colin's big chunk of stuff landing in the Inbox, let's review it, push<br>
to trunk when ready, and then I'll update my MC test hacking, and<br>
resubmit.<br></blockquote><div><br></div><div>I've been meaning to review that, but I wanted to get these changes done before I forget how they work. :-)</div><div><br></div><div>Colin</div></div></div></div>