----- Original Message ----- From: "Peter Donald" <[EMAIL PROTECTED]>
> >2. Property values can be changed and the new property value will be > available > >to any tasks that are runtime subordinate to the current task. > > +1 - unless overidden I am assuming that you are referring to the ability to set a property higher than the current scope? > >3. If a property value is changed by a Task, and the lifecycle of the said > Task > >ends, the property value reverts to its original value. > > +1 if this occurs by default however overall I think a task should be able > place a proeprty in any upper context - most will choose top level context > or current context but some may push the value up two context levels etc > (ie Tinderbox system) +1 > >1. A tree that holds the physical Task structure. This contains Task > instances > >and its parent-child relationships are the same as the XML file. > > > okay lets ignore 2 as all proposals have to have it in some form. > > Could you submit a few more tasks (using reflection to set properties) that > are relatively simple to descibe how you see 1 as happening. I will look into. I am currently adding the XML parsing. But reflection is next on the list. > I have no problem allowing functionality but I do have a problem doing it > by default. Enabling the functionality comes at a cost (high coupling, > heavier interfaces, harder to maintain backwards compatability) but as it > is not always needed - why should all task writers pay the price? It should > be pay as you play IMHO - the more functionality you use the more complex > it becomes rather than starting out complex ;) I agree, but it would be akin to a modular vs. programming language issue. You don't have to write other methods; you could have only one. It is just a matter of style. It doesn't incur the costs that you think (high coupling, heavier interfaces, harder to maintain backwards compatability). At least not that I see. jim
