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
_______________________________________________________
fluid-work mailing list - [email protected]
To unsubscribe, change settings or access archives,
see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
