[aspectc-user] Clear-box versus Black-box AOP Benefits?

[Olaf Spinczyk]

Hi Frank,

Frank J. Iannarilli wrote:
> Hi,
> 
> 
> I'd like to hear from any of you about any real-life examples where the 
> "clear-box" AOP of AspectC++ has enabled useful capability not possible 
> with "black-box" AOP approaches.
> 
> 
> AspectC++ and AspectJ are examples of "clear-box" AOP.
> 
> 
> Apparently, the so-called "native support" for AOP in Microsoft's .NET 
> (see <http://msdn.microsoft.com/msdnmag/issues/02/03/AOP/default.aspx>), 
> along with Composition Filters and similar, are examples of "black-box" 
> AOP.
> 
> 
> Black-box allows aspect quantification over the public interface of 
> component code (e.g., message interception based), whereas clear-box 
> additionally quantifies over the internal parsed structure of the 
> component code (i.e., requires a near-compiler).
> 
> 
> Thanks!
> 
> Frank J. Iannarilli, franki at aerodyne.com

this question would better be asked at the aosd-discuss mailing list at 
aosd.net, but here are my 2 cents:

Croscutting concerns simply affect private methods and internal 
structures as well as public methods. Consider the typical development 
aspects such as tracing, profiling, and constraint checks. Why should 
aspect-oriented implementations of these concerns be artificially 
restricted to the public interface of classes? There are also many 
examples in the area of production aspects. Consider an aspect that 
introduces a member function into a certain set of classes to save the 
object state as an XML document into a file. Of course, this code has be 
able to access the internal state. Also consider our observer pattern 
example. Here the observers are (by default) informed about a changed 
state in the subject if any non-const member function was executed. One 
could argue that a non-const private member function could only be 
called by a non-const public member function and that the observers 
would be informed anyway. However, in the case of C++ we have friends!

"clear box aspects" (who coined this term?) are more dangerous than 
black box aspects, because in a language like AspectC++ they could break 
the semantics of the affected component code. This is a big problem for 
test, verification, etc. Therefore, means to restrict aspects will 
sooner or later be integrated into AspectC++. However, I believe that 
restricting join points to the public interface of classes is too 
restrictive.

Best regards,

Olaf