Re: [boost] [interest] Type Aspects and compile-time constraints

Subject: Re: [boost] [interest] Type Aspects and compile-time constraints
From: Topher Cooper (topher_at_[hidden])
Date: 2012-02-09 10:58:38

On 2/9/2012 2:54 AM, Beren Minor wrote:
> On Thu, Feb 9, 2012 at 1:35 AM, Topher Cooper<topher_at_[hidden]>  wrote:
>    
>> >
>> >
>> >  The reason is that there is a technology called Aspect Oriented Programming
>> >  that is in widespread use and under active research and development.  In
>> >  general it is an extension to modularization but is usually seen as an
>> >  extension to Object Oriented Programming.  Many, but not all, of the
>> >  concerns it addresses can be handled in C++ with generic programming,
>> >  mix-ins and (for run time aspects) delegation.
>> >
>> >  How about Type Axises?  Seems to capture what you consider distinctive to
>> >  this approach.
>>
>> Actually isn't this description of types over some orthogonal
>> properties quite close to AOP model? As far as I could remember, AOP
>> is also about describing a program along orthogonal aspects (such as
>> security, logging, etc...), right?
>>      
I've researched AOP but never used it -- and using is understanding -- 
so take this with the possibility of misunderstanding on my part but...

I think that the answer is ... yes and no.

AOP does address program concepts orthoganal to the usual ones, but I 
think that what you are addressing is orthogonal to AOP as well.  AOP is 
really about modules, not about types -- this can be misunderstood 
because OOP conflates type and module (not a criticism -- in fact, 
Trellis/Owl, an OO language I developed about the same time C++ was 
originally being developed, used the term "TypeModule" instead of 
class).  Trait-ish things provide, essentially, information about a type 
that can then be used metaprogrammatically.  The point of modules is 
that they provide isolation of their concepts.  The problem with modules 
is that they provide isolation of their concepts.  AOP grew out of a 
belief that this meant that any decision about strict modularization had 
to choose some things to represent as primary (what the modules 
represent) but that other things that are equally important, such as 
security, logging, etc. gets broken up -- duplicated or handled 
differently within each module, even when there are modules (e.g., a 
logging or a security library) to support those concepts ("aspects").  
If you want to make changes to how one of these is handled, one needs to 
go into each module to make the changes.  In most versions of AOP, 
however, one does not have to fully anticipate precisely what 
constitutes an Aspect in advance, and the changes may even be made at 
run time.  Think of AOP (AOP advocates may scream at this, I'm not sure) 
as a framework for tools for editing the source, object or executable or 
running image across a whole program in parallel by describing to the 
tool how to identify what needs to be changed and how to change it 
without needing to deal with each instance.  Perhaps you might think of 
this as a kind of highly sophisticated parameterized 
find-and-replace-all that operates on a level of abstraction beyond the 
text level (even when applied to source).  Trait-ish concepts might be 
used as part of the vocabulary for describing these "cut-points" 
(identifiable places to make changes) but they aren't really the same thing.

I'm not sure whether or not I agree with the AOP solution.  It seems to 
me that there should be an extension to OO rather than development 
orthogonal to it that would handle these concerns in a more clean 
fashion, but I can't pretend to know just what that extension would be 
and I might be missing something in the concept that makes it less ad 
hoc, more elegant and concerned with abstractions that are truly beyond 
OO than appears to me.  And, of course, my comment was concerned about 
confusion due to "aspect" having an understood technical meaning (for 
that matter, one in wider circulation than "traits" or "facets"), with 
the utility of that concept being irrelevant.

Topher

Topher