Peter Donald <[EMAIL PROTECTED]> wrote: > On Mon, 18 Jun 2001 20:26, Stefan Bodewig wrote: >> Peter Donald <[EMAIL PROTECTED]> wrote: >> > We have yet to discuss any of the higher order aspects such as >> > those needed by GUMP. They are higher order as they require >> > cooperation from the task to complete the action. >> >> In case of the CLASSPATH aspect, this can probably be solved best >> if you remove all CLASSPATH related stuff from the tasks completely >> - make the tasks rely on the aspect and you don't need cooperation >> at all. >> >> This probably means we need child elements that belong to aspects >> (<ant:classpath> which would just be a nicer way to write the >> corresponding attribute). > > I don't get that at all - can you explain?
Let's take javac as an example. We can remove all setClasspath and addClasspath methods from it. We can have a default Classpath aspect handler that will always be present and simply adds all user specified entries to the current system classpath (or whatever our default policy for classpaths is going to be). So instead of <javac classpath="foo"> <classpath refid="bar" /> </javac> we make that <javac ant:classpath="foo"> <ant:classpath refid="bar" /> </javac> where "ant:" triggers the classpath aspect (see the need for nested elements handled by aspect handlers?). Instead of constructing the classpath itself, the task will then ask its TaskContext for it - which in turn will consult the aspect handler. I know this doesn't really fit into the picture of aspects at all - but I didn't call it aspect in the first place 8-). If you want to go with the aspect oriented ideas, you'll need an interface with a setClasspath or whatever method to be invoked on the task before execute is going to be called, sure. I guess I've just convinced myself that "high order aspects" are not necessarily aspects for me. Stefan
