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
- 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
