Expansion of arguments for fluid.deferredCall with respect to fluid.deferredInvokeCall is anomalous
Description
At present, expansion of options trees presented to the IoC system as descended from the "components" block proceeds by an incorrect algorithm. This frequently appears when applying the expanders "deferredCall" vs "deferredInvokeCall". At present it is possible for this expansion to occur some variable number of times - for example, the test case in FluidIoCTests which is named "stackThroughInvoke" will fail, if the expander in its definition with type "deferredCall" is replaced with "deferredInvokeCall". This is because this substitution will cause the arguments list to be expanded twice, once as part of global expansion and then again when the expander is evaluated. This then discovers the component itself as deposited from phase 1 and attempts to treat it as material for expansion. This algorithm needs to be globally reimplemented, especially with respect to the more fine-grained "options expansion with priority" functionality that is upcoming.
Environment
None
Attachments
2
Activity
Show:
Colin Clark December 16, 2010 at 12:33 AM
I've reviewed Antranig's changes for this issue and they look generally reasonable. +1 for inclusion in Infusion 1.3.
Antranig Basman December 7, 2010 at 9:28 PM
Fixed at revision 10335, along with numerous other fixes for consistency and correctness of the IoC system - including "noCopy" for invoker arguments, and "proleptic ginger nicknames"
Antranig Basman December 3, 2010 at 9:06 PM
Updated version of patch with resolution for issue - still needs more tests and description
Antranig Basman October 5, 2010 at 7:22 AM
Going on holiday patch. Perhaps it really is time to sign up to github
At present, expansion of options trees presented to the IoC system as descended from the "components" block proceeds by an incorrect algorithm. This frequently appears when applying the expanders "deferredCall" vs "deferredInvokeCall". At present it is possible for this expansion to occur some variable number of times - for example, the test case in FluidIoCTests which is named "stackThroughInvoke" will fail, if the expander in its definition with type "deferredCall" is replaced with "deferredInvokeCall". This is because this substitution will cause the arguments list to be expanded twice, once as part of global expansion and then again when the expander is evaluated. This then discovers the component itself as deposited from phase 1 and attempts to treat it as material for expansion. This algorithm needs to be globally reimplemented, especially with respect to the more fine-grained "options expansion with priority" functionality that is upcoming.