2009/10/28 Stéphane Ducasse <stephane.duca...@inria.fr>: >> >> 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?
sure, why not :) > >> 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? > well, my initial idea is to enable a package developer to establish own policy for his package. A policy get notified of any change before it made and of course doesn't cares if there's anyone who listens for notifications of changes, after they applied. The open question, is how to allow developer to not only use predefined set of flags for policy, but also introduce own custom rules. For example, one might want check the submitted method against lint rules, and prevent method from being installed if rules not satisfied :) >> 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? > Simple. a) In case of any changes, the class environment should be notified, NOT some global. b) in a future, i want to change the class environment to be a package, to which it belongs to. Hence, the package could have own, unique policy, or refer to system-wide one. But it is package, who receiving notifications first, and should be first who in control how to handle them. >> 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 Yes, we can (c) Its good that you remind me about announcements framework. And you are right, that implementing this using announcements is good idea. But i feel a bit uncomfortable facing the need to spawn a lot of (sub)classes for that purpose. Obviously, the kernel should handle all of system events without exceptions, hence a kernel doesn't really needs to know such finely defined subclasses. While other subscribers may want to selectively listen for different things, which happening in a system. So, i want to hear what you and others think about it. > - slowly move from there. > > Stef > > _______________________________________________ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
