> From: peter reilly [mailto:[EMAIL PROTECTED] > > On Tuesday 18 November 2003 17:05, Jose Alberto Fernandez wrote: > > > > My major issue with the current implementation proposal is that it > > touches way too many places in the code. It needs to change the > > implemention of almost all the usages of sequential (and target). > > This is not quite true. It does change the implementation of > target and task but usage of these should not need to change. > For example ant-contrib has a <outofdate> task with a > <sequential> element. This works correctly as a local block > without any changes to the implementation of Outofdate: > > <target name="outofdate"> > <local name="l" value="outer"/> > <ac:outofdate> > <ac:sourcefiles/> > <ac:targetfiles path="file-not-present"/> > <ac:sequential> > <local name="l" value="in outofdate"/> > <echo>l is '${l}'</echo> > </ac:sequential> > </ac:outofdate> > </target> > > prints out "l in 'in outofdate'". >
Would it work if my task extends Sequential? How about if my task just implements TaskContainer interface? By having just a regular task that controls the feature there is less room for confusion between which tasks do provide access to the feature and which do not. For example, what is the effect of having something like this: Assume I have a task that accepts as an element a task. It does not uses sequential, just gets the task element and executes it. What happens if I pass a <local/> declaration as the element? What would be the lifetime of the property being defined? Can we make sure the span is just the execution of the <local> itself? What if I just create a <local/> task using script? Can I violate the scoping rules by doing things like that? With the <local>...</local> version, there are no issues, because the scope is syntactically defined by the task itself. Hope this is compelling enough. Jose Alberto > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
