Boost logo

Boost :

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.



Boost list run by bdawes at, gregod at, cpdaniel at, john at