topological update refactoring

[GoogleCodeExporter]

Overview of todo:

Topological update uses AbstractBeed instead of Beed, because we need 
getDependents(), and 
we do not want that method to be public, because who the dependents are is 
considered a secret 
shared between the dependent and the update source. This is typical for 
Observer / Observable, 
because otherwise 3th parties could get at the listeners, and trigger fake 
updates. This weirdness 
(of using AbstractBeed instead of Beed) causes design problems of all sorts.

1) This is nonsense: the pattern of keeping the list of listeners a secret 
shared between the 
observer and the observable, is ok, and is necessary, because the observer is 
normally an 
interface, and the update method is public, so anyone could trigger the update. 
In this case 
however, Dependent happens to be a class (which is needed for other reasons, 
namely the 
difficult MRUSD implemantation), and the update method actually is protected 
and package 
accessible, but not public. In this case, there is therefor no reason to keep 
the dependents 
secret. This must be changed.

2) If we make this so, getDependents() becomes a public method in Beed. So, 
anyone can get at 
the dependents. The dependent objects are therefor, in practice, not a shared 
secret (and they 
don't need to be, see point 1). In the traditional Observer / Observable 
pattern, it makes sense to 
make the listeners inner objects of the class they service, to keep the secret 
(the update method 
is public). Nobody should be able to get at the listener objects, except the 
Observable, to warn 
them, and the object the listener is working for. In this case however there is 
a) no reason to 
keep the dependent secret (see point 1). Furthermore, b), there is exactly 1 
dependent per 
dependent beed (this is a property of the topological update algorithm. a) and 
b) together mean 
that we don't need Dependent as separate objects: we should merge the code of 
Dependent into 
a Beed subtype, e.g., AbstractDependentBeed. This will make i) a lot of code a 
lot easier, and ii) 
use less memory, and iii) make the algorithm faster. Potentially, there are 
also benefits with 
respect to the MRUSD algorithm, but that is only a hunch.

These changes are probably really necessary for CompoundEdit.

Original issue reported on code.google.com by jandockx on 3 Jul 2007 at 7:40

[GoogleCodeExporter]

Original comment by jandockx on 3 Jul 2007 at 7:42

• Added labels: Milestone-Release-II

[GoogleCodeExporter]

Original comment by jandockx on 3 Jul 2007 at 7:42

• Added labels: Milestone-Release-I
• Removed labels: Milestone-Release-II

[GoogleCodeExporter]

Original comment by jandockx on 3 Jul 2007 at 7:43

• Added labels: Milestone-Release-II
• Removed labels: Milestone-Release-I

[GoogleCodeExporter]

Original comment by jandockx on 3 Jul 2007 at 7:47

• Added labels: Priority-Critical
• Removed labels: Priority-High

[GoogleCodeExporter]

There is a snag: we still need access to a package accessible "fireEvent" 
method in the beed from the topological 
update algorithm. Since beed is an interface, we can't do this. So, we need a 
class. Either we stay with abstract 
beed, which all beeds must extend, or we introduce a "BeedImplementation" super 
class above abstract beed 
with just that 1 method, or we use some other form of accessing this difficult 
method (a "caller" object, functor, 
closure, whatever).

Original comment by jandockx on 6 Jul 2007 at 1:09

• Changed state: Started

[GoogleCodeExporter]

This is done in first phase, differently than described originally. Still left: 
merge Dependent into 
AbstractDependentBeed. We keep using the mandatory inheritance from 
AbstractBeed for Beed implementations, 
for access to the "fireEvent" method. Beed interface is still needed for type 
multiple inheritance in Beeds.

Original comment by jandockx on 22 Jul 2007 at 11:29