|There's more than one way to do things|
Re^4: Aspect-Oriented Programming: Couple of Short Examplesby adrianh (Chancellor)
|on Aug 06, 2003 at 17:24 UTC||Need Help??|
Could you elaborate a bit what you meant by "static language" versus "dynamic language"? I don't think I understand. Thanks.
I was searching for a more diplomatic term for the LFSP/LFM divide :-) Perhaps some examples will illustrate.
In an language with metaclasses you can isolate behaviour to a metaclass in a similar way to the way you move behaviour to an aspect. For example, in Python you could add behaviour to object initialisation by creating a custom __init__ method in a metaclass. See A Primer on Python Metaclass Programming for an examples.
In languages with eval() like functionality you can make runtime changes to your codebase. Perl developers regularly do code generation at compile time. In languages like Java this is impossible. Aspects give some of this power to Java.
In languages that support mixins and other forms of multiple implementation inheritance you can separate out some concerns into separate class-hierarchies.
If you have mixins, metaclasses, macros, runtime access to your language, etc. you find that you need aspects less. Many uses of aspects in languages like Java are to get around issues with Java's design (e.g. the use of AspectJ to create mixins).
This isn't to say that AOP is a useless or unoriginal concept. There is still the core difference from normal OO code in that an aspect imposes a behaviour on a class, rather than a class requesting behaviour from an aspect.
However, IMO, the arguments for AOP are less compelling when your language is more flexible.