[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue 3072: Nested overrides get confused with multiple contexts in
|
From: |
dak |
|
Subject: |
Re: Issue 3072: Nested overrides get confused with multiple contexts in play (issue 131770043 by address@hidden) |
|
Date: |
Sat, 23 Aug 2014 21:41:42 +0000 |
On 2014/08/23 20:40:21, Carl wrote:
On 2014/08/16 18:55:57, dak wrote:
> On 2014/08/16 18:36:50, lemzwerg wrote:
>
> If you like the encapsulation, you like the patch for issue 2507.
If you like
> that nested properties will just work without handwaving and ifs and
buts, you
> like this issue.
I really like this solution. I spent some time trying to figure out
how to get
reverts
right during my work on beaming; I never found a good algorithm.
Neither did I, and I spent a non-trivial amount of time over the last
years (there are some rather old "I will do this" kinds of comment on
the respective issues that were actually bolstered by sketches, code,
planning, pseudocode etc). So this does not even try. It just
reapplies all remaining nested overrides from scratch when a result is
needed, with some caching/memoization to avoid the effort for some
trivial but frequent situations (like not using nested overrides at
all). I am still not 100% sure that it would not have been doable in
the original spirit. But I'm pretty sure that it would have been very
hard to convincingly prove correct.
I spent a lot less time on writing this version that I spent on trying
to get the problems from the original approach under control. And I
spent no time at all now on drawing diagrams of data structures and
brooding over their implications depending on the order in which several
modifications were applied. The remaining bugs after getting the stuff
to compile were of the "stupid typo" rather than "weird special case"
type. All that is a good sign.
I love the encapsulation. Separating implementation from function is
always good.
Well, the bookkeeping of the internal data structures was scattered all
over the place. Keeping it in that manner would not have been prudent
given the additional complexity. I probably spent more time on the
encapsulation than actually replacing the internals.
https://codereview.appspot.com/131770043/