<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Apr 9, 2014 at 3:31 PM, Chris Muller <span dir="ltr"><<a href="mailto:ma.chris.m@gmail.com" target="_blank">ma.chris.m@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">>> Except for a proxy bug which needs fixed, I'd love to know how you<br>
>> would possibly improve it even if you could do so by the mere snap of<br>
>> your finger. Because I wanted the best of both worlds. I want 1) the<br>
>> ability to clean / reduce an image, 2) WITHOUT losing the ability to<br>
>> retrieve the ancestry. Oh, and 3) it'd be nice if I didn't have to do<br>
>> a special UI operation to "retrieve the ancestry", just have the<br>
>> system retrieve it automatically please only if I do something in the<br>
>> IDE that requires it.<br>
>><br>
>> Again, assuming all the proxy-bugs fixed, what more could one want in<br>
>> terms of meeting all the demands we want as developers?<br>
><br>
> How about not downloading megabytes of data from the network when I didn't<br>
> tell it to do that?<br>
<br>
</div>There are lots of operations in the IDE that cause network accesses,<br>
and none of them advertise in advance that they'll access the network.<br>
So this argument is not really a good one against.<br></blockquote><div><br></div><div>Good grief. If I click on something in the IDE, I've told it do something. Depending on what I click on, network access may be quite reasonable. I'm not going to be surprised if opening a repository inspector on a remote repository needs to download data from the network.</div>
<div><br></div><div>On the other hand, network access when you're using "chase pointers" is not expected. It's also surprising when "Smalltalk fixObsoleteReferences" starts downloading packages from SqueakSource. </div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">> Proxies are a<br>
> useful tool, but they should be kept in the bottom of the toolbox and only<br>
> used in special circumstances. The vanilla image shouldn't have proxies.<br>
<br>
</div>I think this is your best argument. I agree Proxies are a powerful<br>
tool to be used sparingly with deliberate care, but it basically boils<br>
down to using a become:, which we already use in numerous other places<br>
in the image.<br>
</blockquote></div><br></div><div class="gmail_extra">Become is fine. The problem is #doesNotUnderstand:, combined with not subclassing Object. Operations like chasing pointers, which are normally safe, become decidedly unsafe when applied to these proxies. Again, they shouldn't be in the vanilla image.</div>
<div class="gmail_extra"><br></div></div>