Re: [aspectj-dev] Aspect for AspectJ Library: Transparent Usage of Prefe

["Wes Isberg" <wes@xxxxxxxxxxxxxx>]

Thank you for the proposed aspect.

It is very hard to write a reusable aspect.  In this case, you advise
all fields in all subtypes as if they all had preferences.  And if you 
do adopt the convention of static fields, then you would likely get 
enmeshed in Java's interesting class- and static-field initialization...

Another approach would be to use annotations or enumerated pointcuts to 
specify fields backed with preferences, or to have read/write points,
or to adopt naming conventions or a combination: specially-named
getter/setters - all depending on whether the programmer should be
concerned with whether something is backed by a preference.  Perhaps
aspects supporting Sun's Preferences could work along the lines 
set out by aspects supporting other forms of dependency inversion
(IPreferenceable.usePreferences?).

In my mind there are four classes of AspectJ code to publish:

- A particular solution that works

- A working solution with a particularly new or useful approach

- A reusable working ....

- ... that has general applicability

All are great on the user's list.  The later ones are sample code,
and the last one is perhaps a library aspect.  (There are of course 
other considerations - maintainability, clarity, coolness, etc.)
I find that code progresses through these stages; I get something
that works, then find a better way to make it work (on the user
list?), and so forth.

I also liked your problem and solution statement.  You might use the
notions of scattering/tangling and/or crosscutting explicitly to 
see where AspectJ helps.

Wes

> ------------Original Message------------
> From: "Vaidas Gasiunas" <gasiunas@xxxxxxxxxxxxxxxxxxxxxxxxxx>
> To: aspectj-dev@xxxxxxxxxxx
> Date: Fri, May-6-2005 2:19 AM
> Subject: [aspectj-dev] Aspect for AspectJ Library: Transparent Usage of Preferences
>
> Hello to everyone,
> 
> Sorry, for formatting problems in the previous posting.
> 
> Here is a proposal for an aspect to be included in AspectJ library.
> 
> Problem statement:
> 
> Applications require preference and configuration data to adapt to the 
> needs
> of different users and environments. JSDK provides Preferences API to 
> store
> and retrieve such preferences. Below is an example how they can be 
> used:
> 
> import java.util.prefs.Preferences;
> 
> public class Application {
>      public static void main(String args[]) {
>           Preferences appPrefs =
>                Preferences.userNodeForPackage(Application.class);
>           if (userPrefs.getBoolean("showWelcomeScreen", true) {
>               showWelcomeScreen();
>           }
>         ...
>       }
> }
> 
> public class PreferencesEditor
> {
>      public void setWelcomeScreen(boolean on) {
>            Preferences appPrefs =
>                   Preferences.userNodeForPackage(Application.class);
>            appPrefs.setBoolean("showWelcomeScreen", on);
>      }
>     ...
> }
> 
> The problem with such usage is that it is error prone. For example we 
> can
> mistype the name of the property "showWelcomeScreen", we can also make 
> wrong
> assumption about its type, for example it can be stored using numbers 0 
> and
> 1. Default value must be provided in each place where the property is
> requested. Refactorings which imply renaming or removing prefences can 
> lead
> to undetected problems.
> Finally, it would be difficult to change the way application stores its
> properties.
> 
> 
> Solution:
> 
> The idea is to provide preferences as static class fields and write a
> reusable aspect, which takes care about retrieving and storing these
> properties. The classes containing preferences are marked by 
> implementing
> PreferenceContainer interface.
> 
> public class AppPreferences implements PreferenceContainer {
>     public static boolean showWelcomeScreen = true;
>     /* initializer specifies the default value */
>     public static String logFile = "./application.log";
>     ...
> }
> 
> public class Application {
>     public static void main(String args[])
>     {
>         if (AppPreferences.showWelcomeScreen) {
>              showWelcomeScreen();
>         }
>         ...
>     }
> }
> 
> public class PreferencesEditor
> {
>     public void setWelcomeScreen(boolean on) {
>          AppPreferences.showWelcomeScreen = on;
>     }
>     ...
> }
> 
> Such solution make their usage of preferences simple and type safe. 
> This way
> of preference usage supports useful IDE features, such as code 
> completion
> and reference search. The way preferences are actually retrieved and 
> stored
> (Windows registry, properties file, xml file, etc.) can be easily 
> changed by
> configuring the aspect.
> 
> See the first version of the aspect in the attachment (tested on AJDT
> 1.2.0M3 + Eclipse 3.0.2). Comments are welcome.
> 
> Regards,
> -----------------
> Vaidas Gasiunas
> Software Technology Group
> Darmstadt University of Technology
> Hochschulstr. 10
> 64284 Darmstadt, Germany
> 
> e-mail: gasiunas@xxxxxxxxxxxxxxxxxxxxxxxxxx
> phone: +49 6151 16 5478
> fax: +49 6151 16 5410
> www: http://www.st.informatik.tu-darmstadt.de/
> _______________________________________________
> aspectj-dev mailing list
> aspectj-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/aspectj-dev
> 
>