----- Original Message ----- From: "Peter Donald" <[EMAIL PROTECTED]>
> At 11:40 15/1/01 -0500, James Cook wrote: > >I dont agree that having a runtime tree (of variables) adds complexity. It > >is already there in the code now, and it is extremely simple to understand > >and maintain. It also has the benefit of maintaining scope because it is not > >flat. > > I am not advocating a flat space - just the appearance of a flat space to a > task writer (unless they are one of the few who set properties and may need > to crawl up the tree). I think the requirements would be: 1. Supply a property system that works in a scoped manner. 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. 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. 4. Task developers should be able to declare properties that are global. > >Keeping it in the engine means that you don't have to pass anything > >around either. This is patterned after the concepts of an interpreted > >language or a compiler, so we can feel sure that it works well. > > Okay - now I am confused ;) From what I understand you now have three trees. > > 1. Proxy tree - contains the data required to build the tasks > 2. Runtime tree - contains the actual task instances > 3. Data tree - contains the properties, stack trace, etc > > So obviously I have got something wrong. Feel free to correct me ;) I have two trees... 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. 2. A tree that gets built on the fly that functions as a stack and holds property values. This is the HierarchicalHashtable. > >The execution path of a build script should be open to modification if the > >user requires it. Why not? If it is not necessary for a particular user, > >then they don't have to use it. It comes free with the design. I can't > >imagine why we would want to keep this power out of the hands of the power > >user if it can be completely transparent to those who don't want to use it. > > Just because you can - doesn't mean you should ;) That would be the > flexability syndrome. Obviously I don't understand your design thou so I > could be wrong but it seems the only reason you need the runtime tree (as > defined in 2 above) is so you can do this. If you didn't need this then you > could do away with tree 2 all together ... Ant is being pulled in quite a few directions by ppl who *want* to modify runtime characteristics. They are doing this via the <if> tasks and the <select> tasks. Also they want this functionality in the <script> task, so I think that it is a no-brainer. I contend that it is better to incorporate this type of flexibility now, at design time, rather than shoehorning it in at a later time. As you guys can atest to! :-) jim
