2009/10/27 Igor Stasenko <[email protected]>: > 2009/10/26 Stéphane Ducasse <[email protected]>: >> so what is the fix? >> I would really like to get announcement instead of event >> systemNotification but I'm sure that this >> can be a bit tricky. >> > > Yes, tricky :) > Here what i have in mind: > > 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
Hi Igor, IMHO, nowadays, the trend would be to create subclasses rather than internal symbols... Shouldn't there be a symmetry with the hierarchy of changes in DeltaStream (for example) ? Nicolas > - 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 > > 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). > 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. > > 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. > >> Stef >> > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
