Aspects and a Few Language Musings
Join the DZone community and get the full member experience.Join For Free
I wanted to write some code for generating events when properties on
certain key entities change. Of course, we all know that there was
nascent support for propertyChangeListeners in the ‘bean‘ code way back
to the beginning of Java time. In general, though, it seems kind of
ugly to add the same code into a bunch of different listeners; sounds
like a perfect use of aspects (though, I am not one of those people who
argues that AOP has few and limited applications (pun intended)).
First thing I did was go to Manning to see if the 2nd Edition of AspectJ in Action was ready yet. Yup, it‘s in early release. So I got that and started through it. I already liked this book a lot, though I think I said that the first one fell a little short of making the argument for AOP being a central, mainstream approach (whereas the excellent Jacobson book goes the other direction and rethinks all programming back to the Liskov Substitution Principle). I am curious and intend to compare the two editions, but this one reads really well from this perspective, and in some ways that are rhetorically sophisticated too: the core arguments are laid out, but then the book goes into some concepts that are already mainstream elsewhere, e.g. CSS and triggers in DBs, etc. There is a LONG section with examples of pointcut syntax, which is good.
Searching the PDF, I found that in fact the book had an example of doing propertyChangeListeners, using Member Introduction. Kind of cool, done in 2 phases where the first one weaves the propertyChangeSupport into a concrete class, then in the 2nd pass, it uses a marker interface. Strange to me that i have done a lot of AOP but did not really know about ITD/Member Introduction. Love this.
preparing to do this work, I updated my AspectJ plugin to the latest
version (1.7). I turned on the dynamic weaver even though it didn‘t
work at all in Ganymede (using Galileo). Things went ok, though, the
aspect editor does not understand ITD, so
the member shows up as an error. The good news is the error (for
whatever goofball reason) appears only in the editor, not in the
This all happened when I was thinking again about the idea that maybe there are some compelling reasons to consider a new language. I posted about this ages ago, but the thought was this: one of the core problems with OO programming is that the ‘model‘ is a static representation. The first section of Fowler's book Analysis Patterns goes into a health care project where he talks about how developers would model the weight of a person as an integer, but that the person‘s weight is taken each time he/she presents. I tried an interesting idea with aspects not that long ago: writing an aspect that would allow you to get methods like getCurrentWeight() free; an aspect would intercept and fetch from the collective measures store. Of course, all sorts of aggregates would be seamless too, e.g. getAverageWeight(). The advantage is that you could act on the objects themselves. Thinking now that this might be a useful thing to have built into the language itself. Why? Mainly because the straight or static problems. The ones that are easily reduced to simulations of things are going to be largely generated in the near future. The most interesting problems are going to be ones that have to solve for missing data. Been reading a great book on probability (more on that) wherein the author (a cat named Jaynes) makes a great argument in the preface that math spends a lot of its time working problems into all things are known but one, thus the one missing thing can be solved for, but that most problems suffer from incomplete information in a number of attributes/features, and probability is a tool for attempting to formulate solutions in such cases. Which brings me to my last point here: in fact objects are cases. They cannot be more than that. Thus, the idea of embedding aggregates, and shorthand ways of referencing specific cases, is not really foreign; it fits the model.
Opinions expressed by DZone contributors are their own.