Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [aspectj-users] Newbie question on inter-type member declarations 
interessting insights. thank you

Wes Isberg wrote:

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





_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/aspectj-users

Back to the top