distributeOptions

[Antranig Basman]

Hi Yura -

One thing I recalled just now is that there already is a partial answer to "deleting grades" as you were 
asking today, since I remembered that I had improved the implementation of "distributeOptions" so it is 
capable of completely replacing a typeName of a subcomponent by downward distribution. Of course it can't 
currently interfere with the contribution of further gradeName through arguments or dynamic grades, but 
demands blocks couldn't do this either - this does mean though that as far as I can see, "distributeOptions" 
really does cover 100% of the power of demands blocks (as well as having plenty of other capabilities too).

In general I worry about providing the capability to negate grades since this carries us outside the scope 
of the only formalism I've found that describes something like our system for dynamic grades, written up in 
this paper from Google Israel: http://tal.forum2.org/static/cv/ObjectEvolution.pdf - the authors stress the 
importance of "monotonicity" in type evolution in maintaining the consistency of a design. On the other 
hand, the "type replacement" described in my first paragraph could be said to have lost us this consistency 
already... all the same, I'd like us try to resolve any of our grade modification requirements case-by-case 
with our current system before opening the floodgates with a new feature that would require its new syntax. 
However, as I mentioned, if we did implement such a facility it might be through the features supplied by 
http://issues.fluidproject.org/browse/FLUID-5045 when it is implemented - if we can mix model transformation 
documents in amongst IoC material, we could make use of their already existing syntax to express deletion 
(the "delete" transform rule).

One thing that sets us apart from the discussion in the Google paper is that you couldn't consider our 
dynamic grade system as permitting "reclassification" as such, because all of the computation relating to 
the final grade content happens BEFORE any instantiation of the object occurs (with the exception of the 
material required to resolve any dynamic grades). Once a component has been instantiated, its grade content 
can't be changed. This may mean we can avoid the stability issues described in the paper - we are only 
exposed to them in the case that a dynamic grade expression depends on parts of a component's options which 
themselves depend on the final value of the dynamic grade - which is already a risk we need to highlight to 
framework users.

Cheers,
A