On Wed, 11 Apr 2001 14:44:55 +1000, Peter Donald wrote: >At 08:48 9/4/01 -0700, David Rees wrote: >>On Tue, 03 Apr 2001 22:10:57 +1000, Peter Donald wrote: >> >>>At 02:00 3/4/01 +0200, Stefan Bodewig wrote: >>>>Peter Donald <[EMAIL PROTECTED]> wrote: >>>> >>>>> However it is at higher complexity build files (medium->high >>>>> complexity) where the advantage would be shown. Mainly as it would >>>>> allow core to be clean and handling of tasks predictable. For big >>>>> build processes it would allow customisation without magic variables >>>>> (ala GUMPs sysclasspath) and added value (ie assign fee: namespace >>>>> to something specific to buisness). >>>> >>>>So you propose namespaces to make the "aspect" system pluggable, am I >>>>getting this right? You want a facility to say "I'll take >>>>responsibility of all task attributes int the baz namespace"? >>> >> >>I think the "simpler" alternative of introducing a context object with >>sub-elements should also be kept for consideration. I think it would >>easier for many to understand. Then taking control of logging is as >>simple as replacing the logging object. It also moves the >>logging/failure attributes out of Task, which I think is the right >>thing to do. >> >>In terms of big build processes you could have a set of named contexts >>defined to plug in and out. > >I am not sure why you think such a system would be simpler. Aspect based >systems are meant to be used to give fine grain separation of concerns. How >the aspects are handled (ie Facilities in my terminology) is not set. In >essence what you propose is to reclump all aspects into one again and then >swap out facilities at runtime (ie essentially what Ant1 does with it's >magic properties/loggers). > >This of course fails to provide for large projects who want need the extra >flexibility to do their own thing. It also doesn't add anything on an >aspect based system because we could always directly configure facilities >to provide appropriate fgeatures (ie special ClassLoaderFacility for GUMP >builds, BlameFacility for Alexandria, DocFacility for AntDoc etc). > >So I can't see how it is simpler or more useful for the **users** (though >it would be simpler for us Ant developers). >
I think are concepts are the same and its more of an API question rather than one of aspect orientation. As a big proponent and someone who has coded aspects into the compiler in those languages that I could (Smalltalk) I don't think I am arguing against aspects. In fact, in my experience, most aspect oriented solutions are not visible in the code at the point where they are used. Instead, they are installed/uninstalled as part of that classes configuration. What I am suggested is that context represents this API for installing/uninstalling aspects. As that they are explicitly supported in the API. I see the logfile attribute being on a LogContext element like: <Context id="detailed"> <LogContext name="current" logfile="log.txt" /> </Context> and I think you see it as a namespace delimited attribute (right?) on the task itself: <Copy log:file="log.txt" /> I prefer the former approach because (IMO) it makes easier to install/uninstall whole approaches for running tasks: <Project context="detailed" ... /> <Copy context="ignoreMost" ... /> Now that I have looked at a possible API for what I suggest, I do agree that it may not really be simpler for the user since the basic user will not even be aware that namespaces are being used. However, I do think the flexibility for installing/uninstalling whole contexts is key and I am not sure how you propose to handle that from an XML api perspective. dave
