On 2/9/2012 2:54 AM, Beren Minor wrote:
On Thu, Feb 9, 2012 at 1:35 AM, Topher Cooper<topher@topherc.net> 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