ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <dona...@apache.org>
Subject Re: [DISC] Aspect types was [DISC] Aspect implementation
Date Sun, 03 Jun 2001 00:38:29 GMT
Hi,

At 07:41 PM 6/2/01 +1000, Conor MacNeill wrote:
>>
>> So before we define the Aspect interface I think we should try to
>generate
>> a list of aspects that we think would be valid to implement.
>
>That sounds a reasonable approach although I feel we may be able to
>identify the "hinge points" just from our understanding of how Tasks will
>be executed.

true - perhaps there could be others related to interaction between
targets/projects and/or changes of ExecutionFrame.

> The other thing I mentioned in a separte post is identifying
>to which elements or tasks the aspect is to be associated. With a debugging
>aspect, for example, we may want to apply to a number of task types without
>having to enter aspect style attributes into each task declaration.

nicer programatically and could be useful for tracing likethings .... hmmm
... wait...

Brilliant. On second thoughts this could be far far more useful. So every
aspect handler gets an opportunity to do something at each hinge/join
point? (or maybe every point they "register" for. I like.

For ages I have been trying to figure out a clean way to do preferences. In
many ways preferences is a specialized form of templating .. namely if
attribute foo not set and we have preference set for it then we set it.
This could be done as a preference easily enough (something that gets hold
of task model + task instance before execute() is called on task).

+1 on Preferences == Aspect

> This
>might lead us into what AspectJ calls pointcut designators. If so, we'll
>need some syntax for that. Or is that too complex for now.

man they have complex names for simple concepts ;)

>I don't think there will be many aspects in practice but you neve know.
>Anyway, the types of aspects to date I have considered
>failonerror control
>id definition
>debugging/tracing aspects
>perhaps logging but I haven't thought about it.

+1 for logging.

>Your example contained a doc: aspect but I had always theought that was
>piggy backed to the aspect concept as a way of ignoring some elements. That
>is, I didn't really expect the core to process these in anyway. Thoughts?

agreed.

>Do we agree that an aspect can be in the build file without there being an
>aspect handler defined for that and if so, those aspect attributes are just
>ignored

I am not sure - I think there should probably always be an aspect handler
for it. However we could define a NoopHandler that would be installed for
certain predefined aspects by default (much like DefaultListener is
installed as ProjectListener by default).

>Any thought about aspects applied to either target or project elements?

It could be useful to have the adapter between tasks/target/project and
ProjectListener as an aspect. But that is more a programatic advantage
rather than advantage to build file users ;)

Cheers,

Pete

*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof."                   |
|              - John Kenneth Galbraith               |
*-----------------------------------------------------*


Mime
View raw message