> -----Original Message----- > From: Peter Donald [mailto:[EMAIL PROTECTED]
> At 10:48 15/1/01 -0500, James Cook wrote: > >The runtime tree allows variables to have scope much like a > compiler engine > >works when making nested or recursive method calls. > ...snip... > > Right but that is not neccessary. You can simply pass around a "context" > tree. The context tree would have all the information needed - such as > properties, environment conditions and probably stack trace. By removing > the necessity of runtime task tree you vastly simplify the design and you > revert to something more people can understand. Everyone can > understand the > "context" subject because it is basically a hashtable or > properties object ;) 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. 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. > >Also, scripting support would benefit greatly from being able to > dynamically > >change the execution path, > > -1 > Execution path should *never* in my opinion outside of a very few rare > occasions (ant-call comes to mind) be able to do this thou YMMV ;) YMMV? 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. jim
