Adrian Colyer has written a blog on using aspects as automaton, with an example of implementing an aspect that polices rules based on sequences of join points in the execution of a program.
It’s based on AspectJ 5, and walks through a validated foo/bar transition. What uses might you have for this kind of feature? Do you think workflow or business procedure implementations might use something like this?
-
Using Aspects as Automaton (4 messages)
- Posted by: Joseph Ottinger
- Posted on: April 13 2005 14:02 EDT
Threaded Messages (4)
- If I only have a hammer... by Tom Gardner on April 14 2005 05:28 EDT
- If I only have a hammer... by Time PassX on April 14 2005 09:31 EDT
- TSS: YOU HAVE A BUG by Time PassX on April 14 2005 09:33 EDT
- If I only have a hammer... by Tom Gardner on April 14 2005 05:50 EDT
- If I only have a hammer... by Time PassX on April 14 2005 09:31 EDT
-
If I only have a hammer...[ Go to top ]
- Posted by: Tom Gardner
- Posted on: April 14 2005 05:28 EDT
- in response to Joseph Ottinger
This technique feels like a case of "if you only have a hammer then everything looks like a nail". Sure the technique is possible, but if this techniques is needed then I'd have serious doubts that aspects were being used wisely.
If this technique is developed further then it will almost certainly evolve to be equivalent to yet another poorly specified Turing-complete scripting language.
But then I have a general principal that I like to keep things simple, transparent, and specified in one place only.
Aspects do have their place and value, but they shouldn't be overused. Perhaps this technique is useful as an example of "too far". -
If I only have a hammer...[ Go to top ]
- Posted by: Time PassX
- Posted on: April 14 2005 09:31 EDT
- in response to Tom Gardner
Interesting. I see your point, to an extent.
But, in the case he's talking about, it's a REQUIREMENT. How else would you enforce it?
You say, "But then I have a general principal that I like to keep things simple, transparent, and specified in one place only."
Well, it IS in one place only (see the final aspect listing at the end of the article). I'll grant it's not the clearest thing I've ever seen, but I'm not sure how it could be any simpler.
Here's the challenge, then: SHOW US how you'd do it more simply, more transparently, and in one place only. -
TSS: YOU HAVE A BUG[ Go to top ]
- Posted by: Time PassX
- Posted on: April 14 2005 09:33 EDT
- in response to Time PassX
Hey, just noticed that my reply above is credited to "Time Passx", with a link that shows posts by several people. HOWEVER, I'm not that person/place/thing! -
If I only have a hammer...[ Go to top ]
- Posted by: Tom Gardner
- Posted on: April 14 2005 17:50 EDT
- in response to Time PassX
Interesting. I see your point, to an extent.But, in the case he's talking about, it's a REQUIREMENT. How else would you enforce it?You say, "But then I have a general principal that I like to keep things simple, transparent, and specified in one place only."Well, it IS in one place only (see the final aspect listing at the end of the article). I'll grant it's not the clearest thing I've ever seen, but I'm not sure how it could be any simpler.Here's the challenge, then: SHOW US how you'd do it more simply, more transparently, and in one place only.
In order to do that properly, I would have to go back to the original requirement and constraints, then consider whether Aspects were the most appropriate implementation technique (given Aspects' relative strengths and weaknesses). That isn't possible since the article was only intended as a pedagogical illustration of a limitation ad a workaround.
The proposed technique appears to be a solution to a problem introduced by a particular implementation technique (i.e. Aspects). In such cases it is often better to use different implementation technologies. But that's a restatement of the title :)