avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <nicola...@apache.org>
Subject Re: [PROPOSAL] lifecycle release
Date Mon, 17 Mar 2003 22:18:33 GMT


Stefano Mazzocchi wrote, On 17/03/2003 22.09:
> Noel J. Bergman wrote:
> 
>>> BTW, I'm still thinking about the logging thing.
>>> Imagine that we have all logging calls done like this:
>>>  //@log("hello log");
>>> we would have logging disabled by default, but we can transform the
>>> class to use logging when running
>>
>>
>> We do something similar in James with Ant, but the changes are at compile
>> time.
> 
> 
> Right, that's how almost everybody does aspect-oriented things today but 
> code preprocessing is evil. 

Not evil, just evilly done. Copying sources just to filter... why can't 
the compiler do it? Taht would be a cool AOPed compiler. Imagine that we 
feed the compiler a filesystem that has file requests intercepted by 
filters... an extensible compiler! ;-)

> Java cries for a little more aspect 
> orientation but aspectj (or even worse hyperj) are simply too much.
> 
> Nicola's approach sounds hacky as hell.

Ha  :-D

> What we need is a way to add multidimensionality (a-la namespace) to 
> java code, but I can't figure out a way to do it without breaking the 
> java syntax.

Hey, that's what I am doing! :-PPP

really-Poor-man AOP? Sure. Like javadoc tags are really-Poor-man attributes.

Seriously, think about it a minute.

Aspectj AOP says that their AOP it's good for logging, which is 
generally *wrong*.

Aspects like logging are nice to do what there is a /pattern/ in code 
that can be more syntetically be described by AOPish definitions. But if 
you don't have the way of making it more generic, you will just move the 
same code out of the file and just point to the source to where it must 
be called.

We cannot use interceptors. There are two types of interceptors, 
interceptors that are called when an object is constructed and 
interceptors that are called when methods are called, but none can 
easily map log calls to *parts* of a method.

So I asked myself: what system is there that makes these aspects not 
make java code inconpatible with normal java compilers? Comments.

Then how do we make these logs easily expressible. Put them where they 
belong, in teh code.

Finally, how to make java compile them? Use pre-filtering of the class 
files. This can be done in Ant filtered copies for a prototype, but the 
goal is to add this to the Eclipse compiler so it happens without 
needing copying files.

What is so eeevil about it? What makes javadoc tags as attributes much 
better?

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


Mime
View raw message