>
> Any change to system should be captured _before_ it applied.
> This allows us to introduce a policy which can validate the change
> and decide
> whether it allowed to be made or not.
>
> I made the SystemChangeEvent class, which having following state:
> - changeKind - a symbol, which identifies the change
> - parameters - a dictionary , which holding different parameters,
> important for change
> - subject - the object which is going to be changed (or taking a main
> role in change)
> - action - a block closure which , if evaluated, will apply the
> change to system
why not using announcement?
> For example, here the method which creates & populates the system
> change event:
>
> classify: element under: heading suppressIfDefault: aBoolean
>
> (self subject newSystemEvent: #changeSelectorCategory)
> subject: element;
> param: #behavior->self subject;
> param: #category->heading asSymbol;
> param: #suppressIfDefault->aBoolean;
> action: [ super classify: element under: heading
> suppressIfDefault:
> aBoolean ];
> signal.
> ---------
>
> The event handling procedure is following:
>
> - first of all, an event passed to a system arbiter object
> - a system arbiter checking with the policy
> - if everything ok, change is applied by evaluating action.
> - and finally, change is announced to any interesting parties
>
> I want to make each package to hold own policy (a set of flags
> identified by name, to ease fileout).
Why only easing fileout it seems to me that this is not related to
notification of changes?
> Then, any event could be validated by policy by issuing:
> package policy validate: change
>
> For example, lets see , what validations we could introduce for method
> recategorization event.
>
> - lets take most interesting case, when we want to recategorize the
> method in ClassA, which belongs to PackageA,
> and putting it into extension category, like *PackageB
>
> - check, if we allow any changes to ClassA (policy of PackageA)
> - check if PackageA allows method extensions (policy of PackageA)
> - check if PackageB allows extending the classes of another packages
> (policy of PackageB)
> - check if extension overrides existing method
> - and of course, we should check that given extension does not
> creates a circular dependency between the packages.
I would like to understand why do we want package to get a policy?
> There, of course, some problems which arising.
> - changes nesting.
> Some changes is complex ones, and even a simple method
> recategorization could lead to another event - creating a new
> category in class. Optimally, it would be cool to have only most
> basic events, which can't be nested. And any action which may lead to
> multiple changes, should be split on a number of basic ones.
> A SystemChangeNotifier solving this by allowing doing things silently:
> SystemChangeNotifier uniqueInstance doSilently: [ ... ].
> so, any changes within the block , if any, won't be announced.
>
> - atomicity support. To support the bulk model updating, i can imagine
> the framework, which capturing any changes without applying them, by
> building/collecting all changes in parallel, and then applying them by
> a single mass-become. This is what SystemEditor does.
>
> - metaprogramming. There should be a means to leave a room for
> metaprogramming. We wouldn't want to signal a system change for
> anonymous classes, and many other things, which can be tricky here.
>
> P.S. as you can see , the plans is quite bold, and will require
> numerous refactorings :) So, the more people is interested in that,
> the better.
My gut feeling is to say:
- let us study what is there
- can we migrate to announcement
- slowly move from there.
Stef
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
