On 29.01.2014, at 16:59, Chris Muller <asqueaker at gmail.com> wrote:

> Good morning Bert,
> 
>>> If / when you get into the details of the problem (which, I hope you
>>> do) and begin to wrestle with the issues of compatibility,
>>> performance, transparency, and enabling a variable-sized lookback
>>> history, while still preserving ALL history in case we need it -- At
>>> that point you might strike an appreciation for how well the Proxy
>>> solution aligns itself to the problem and associated issues.  Sure, if
>>> its a ticking time-bomb of nitro-glycerin, we can't use it, but I
>>> never understood why Proxy's are good for so many other similar cases
>>> but not this one.
>> 
>> Because MC is a dev tool, not an end-user application. Having a proxy materialization kick in while you're debugging stuff is highly detrimental. They are inherently unpredictable. Just looking at them causes a cross-atlantic network fetch.
> 
> I feel like I'm reading the same message, which is you don't like them
> anywhere, not just in MC.  Some large database end-user apps are just
> as important as MC.   I doubt you're saying it's okay for such an app
> to endure "highly detrimental", "inherently unpredictable", Proxy's.
> Maybe you mean for a video game it would be okay..
> 
>> The basic problem is that loading the full ancestry happens as a side-effect of some unrelated operation.
> 
> It happens when a message is sent to the Proxy, so it can't be THAT unrelated.

Smalltalk allObjectsDo: …

It is related, but only mediately.


> 
>> You're adding more and more patches trying to avoid materializing the proxies.
> 
> I haven't touched it in months.
> 
>> But you can never be sure you found the last one.
> 
> You can never be sure you've found the last bug, of any type, in any
> system.  But yes, Proxy's are slightly more-challenging to debug, and
> invariably require some "patching".  But, in my experience, once
> they've been debugged, they pay dividends for a long time without
> having to touch it.  That last part is a pattern consistent with any
> implementation.
> 
>> The proper way to go about this is to make Monticello aware that the full ancestry might not be available. Then at a few select places where it really needs the full ancestry, insert calls to load that ancestry.
> 
> Fine, my goal is to have the problem solved, not use Proxy's or
> convince you to like them.  Let's tackle it in 4.6.
> 

I’m in :)
And I’m even more evil: let’s ditch Monticello in its current Form.
It has virtues (let’s keep them) but also areas (like the use of DataStream, 
fully-zips, important but meaningless UUIDs clashing with naming conventions).
Let’s take the best and leave the rest.[1]


Best
	-Tobias

[1]: Do not read as “monticello” is the root of all evil, it is not. But I had had
    enough problems with it to favour a leap.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1665 bytes
Desc: Message signed with OpenPGP using GPGMail
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20140129/f2823efa/signature.pgp