On 28.01.2014, at 23:38, Chris Muller <asqueaker at gmail.com> wrote:

> You weren't clear about that.

Really now, we're down to grammar?

>  Your first sentence said you "don't want to proxify",

Which was citing your commit message.

> then you said, "proxying MC ancestry is a Bad Idea"

Wherein I specify exactly which proxies I am talking about, not the general idea of proxies.

> without saying why,

The whole conversation is about the problems your proxies generate, and it goes back for months, as you remember, so I don't feel the need to restate it.

> and finally you said, "these proxies are brittle,"
> possibly suggesting that another kind of proxy besides THESE proxies
> would fit better..?

No, I wrote "proxying MC ancestry is a Bad Idea", period. 

>  I still don't know which of these three
> interpretations you mean, I guess either the 2nd or 3rd since you said
> not the 1st..

I meant precisely what I wrote. No need to guess. Proxying MC ancestry is a Bad Idea.

> [... derisive schooling elided ...]
> 
> 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.

The basic problem is that loading the full ancestry happens as a side-effect of some unrelated operation. You're adding more and more patches trying to avoid materializing the proxies. But you can never be sure you found the last one.

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.

This would ensure that MC again is fully predictable, which you cannot guarantee with the proxy approach. 

- Bert -

>   [... more vitriol disguised as pity ...]
> 
> On Tue, Jan 28, 2014 at 3:56 PM, Bert Freudenberg <bert at freudenbergs.de> wrote:
>> I am not going to argue your straw man. I am talking about MC ancestry specifically, not proxies in general, as you are well aware. You keep saying "my proxies are great if we just fix this last bug here". I disagree.
>> 
>> - Bert -
>> 
>> On 28.01.2014, at 22:40, Chris Muller <asqueaker at gmail.com> wrote:
>> 
>>> Bert, perhaps Eric Gamma would be interested in debating with you the
>>> validity of Proxy pattern, I'm not.  The only thing I can do is direct
>>> you to works of universally accepted design patterns [1] and scores of
>>> systems that use Proxy's reliably, everyday (including Magma).
>>> 
>>> Further, I already stated I'm not beholden to solving the problem with
>>> the Proxy pattern, yet you continue to hammer your adjectives on it.
>>> Why won't you say something about the problem it's targeting and/or
>>> offer up one of your "much less brittle ways to achieve this..."?
>>> 
>>> [1] -- (see Chapter 4)
>>> http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612/ref=sr_1_1?ie=UTF8&qid=1390944300&sr=8-1&keywords=design+patterns
>>> 
>>> or
>>> 
>>> http://www.amazon.com/The-Design-Patterns-Smalltalk-Companion/dp/0201184621/ref=sr_1_2?ie=UTF8&qid=1390944324&sr=8-2&keywords=design+patterns+smalltalk
>>> 
>>> On Tue, Jan 28, 2014 at 11:26 AM, Bert Freudenberg <bert at freudenbergs.de> wrote:
>>>>> - Don't proxify WorkingCopy ancestry for the release because we still have a bug.
>>>> 
>>>> Chris,
>>>> 
>>>> we don't want to proxify not just because it's buggy, but because proxying MC ancestry is a Bad Idea. There are much less brittle ways to achieve this. Our dev tools need to be rock-solid. These proxies are unpredictable and therefore have no place in a stable release.
>>>> 
>>>> - Bert -
>> 
>> 
>> 
>> 
>> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4142 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20140129/c6ef58ca/smime.bin