> If an object implementing some task can use other objects, we do not need > to split the function part and the beans/reflectable part of tasks into two > objects. Today this is not possible, because task A using task B cannot set > the project variable, as it is private.
In what I've proposed, the properties are a mutable list on the Project object. This means that all tasks should have access to that list and can change them. This would allow task A to affect something that task B does later. > To allow reuse, either split the > task object into one implementing the functionality and one that gets > reflected in and uses the other - OR allow tasks instantiate other task (and > setting the project instance variable). If the second is preferabkle to the > first, make it a general principal, that a task being executed may either be > reflected in or created by another task, which was reflected in. So, of either of these two options (if I'm reading correctly), the latter one is more clear to me. All it would take is allowing the Tasks to look at the list of projects in the currently executing target and modify that list. The question is do we really need that much flexibility? I'd think that at first being able to convey information via the project props would be enough. > Arrgh. I deeply regret not having written "URL object as INTERNAL > representation of resources" - meaning objects (being either tasks or > "functional" objects) dealing with resources, should use an URL > representation, whenever possible. Objects manipulating resources should use > InputStream and OutputStream for their interfaces. To allow good reuse. Ah. Ok. So you're saying the canonical representation of resources internally should be URL objects. The problem with this is that Files have a richer set of functionality than do URLs, including now the ability to set read only flags and a whole slew of useful things in build development. The other negative I see with using URLs is that at least the major base tool that we deal with (javac) can only be used with Files and not with Streams. The new compiler in JDK 1.3 might have a private com.sun.* interface for dealing with Streams (I haven't examined it in detail), but that's 1.3 and given that at least one project contributor is against moving to 1.2, 1.3 functionality is asking too much. In a perfect world, a Streams based approach would be nice, but I'm not sure that we can make that jump yet. .duncan
