Re: [aspectj-users] Newbie question on inter-type member declarations

["Wes Isberg" <wes@xxxxxxxxxxxxxx>]

> can you explain why you dont like any of those solutions?

sure...

> > You might get as much convenience from a utility - variants:
> >  
> >    String.valueOf(x)
> >    Renderer.render(int x)
> >    getRenderer(y).render(y.x, "fieldname")

Rendering is a function of
- type-rendered-to
- type-rendered-from
- semantics of the field
- context of display
- also caching?
so a complete utility solution would be highly parameterized
and know a lot about the other components.  I typically find
that these rendering decisions should be made at the view layer
(by the interface designer) rather than having the domain 
programmer make those decisions; aside from having the expert
decide, often the view layer has more natural support for 
this function.  Just a bias.

> > AspectJ could parameterize around the field name for lazy 
> initialization:

The usefulness of the AspectJ solutions depends on how crosscutting
they are (if not, then why use aspects?) and the overhead/cost.

This next one has reflective overhead, both to access the value and
likely to introspect the type to figure out how to handle it.
(Another option would register renderers for each field-context
pair.)  So the extent of crosscutting depends more on the logic
in the commented part being able to handle all the fields picked
out.  There's no guarantee of that.  And if, or since, the field
name is used as a key, a rename-field refactoring would break a
lot of code.  To my mind, a new subclass shouldn't break the aspect,
but it might here.

> >    String around(Item item) : get(String *AsString) && target(Item) {
> >       String result = proceed(item);
> >       if (result == null) {
> >          // reflectively set field, based on utility call, keyed off 
> > field signature
> >       }
> >       return result;
> >    }
> >  

This next one has the same problem in the default case.  It also relies
on a technique (of using precedence to resolve ITMD collisions)
that is unfamiliar to most programmers.  It forces the developer
to "override" on a per-type basis, so s/he has to sign up for
handling other fields and other types.  However, I can imagine
using the call join point to gather information about the caller
as well, to satisfy per-caller rendering requirements.

> > Or perhaps for each domain element viewable on a web page:
> >  
> >    interface IWeb {  String fieldAsString(String fieldName); }
> >    aspect ImplementingIWeb {
> >        declare parents {domainClasses} implement IWeb;
> >        public String IWeb.fieldAsString(String fieldName) {
> >             // default, reflective implementation
> >        }
> >    }
> >  
> >    /** override default implementation for Item */
> >    aspect ImplementingIWebForItem {
> >        declare precedence ImplementingIWebForItem, ImplementingIWeb;
> >        public String Item.fieldAsString(String fieldName) {
> >             // custom Item implementation
> >        }
> >    }
> >  
> > (I personally don't like any of these options, but they might be 
> worth 
> > considering.)
> >  
> > Hope this helps -
> > Wes
> >  
> >  
> > 
> >     ------------Original Message------------
> >     From: "Are Meisfjord" <are@xxxxxxxxxxxxx>
> >     To: aspectj-users@xxxxxxxxxxx
> >     Date: Mon, Aug-9-2004 2:10 AM
> >     Subject: [aspectj-users] Newbie question on inter-type member
> >     declarations
> >     Hello!
> >      
> >      
> >     I'm wondering if it's possible in AspectJ to add inter-type 
> member
> >     declarations based on pointcuts? A little example to illustrate 
> what
> >     I mean: 
> >      
> >     We have a web application using Struts. For convenience we
> >     have introduced a naming convention requiring certain properties 
> in
> >     our domain model classes to have extra ...AsString properties 
> that
> >     formats the properties correctly for presentation in web pages
> >     (using Struts taglibs). So if we have a property 'salary' in the
> >     Employee class we will also have a property 'salaryAsString' that
> >     returns the salary (originally a double) as a string with 
> thousand
> >     separators and two decimal precision.
> >      
> >     Is it possible to enforce this convention throughout the 
> application
> >     with an aspect? Of course, We could list each ...AsString method 
> as
> >     an inter-type member declaration in the aspect, but that won't be
> >     much of an improvement wrt programming effort. It would be much
> >     better if we could make a pointcut selecting all get and set 
> methods
> >     of interest and then apply an advice on them that added the extra
> >     methods...
> >      
> >     Regards,
> >      
> >      
> >     Are Meisfjord
> >      
> 
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/aspectj-users
>