New_aspect wrote: > What I want to know is,if anybody on a > commercial scale is using AOSD to develop commercial products? I have been using aspect oriented design techniques since 1992, when I invented a name "contextual extension" for a feature that occurred naturally in a data definition language I had designed in 1983. Needless to say, the term "aspect oriented" wasn't then current :-). I introduced hierarchical aspect-oriented design to ManageSoft last year, and we are finding my hierarchical approach (which extends and generalises most of the current AOSD state-of-the-art) helps considerably in the design and requirements phases - because it gives a better framework for SOC. So yes, it's fair to say that AO design *is* being used in a >1MLOC commercial product, which spans C++, Java, C# and Perl as well as a number of proprietry domain-specific languages (for errors, tracing, configuration variables, etc). I should say that our aspect orientation goes far beyond its traditional application to "infrastructure" aspects like logging etc (though we have identified and use over 80 different infrastructure aspects). For example, the ManageSoft product distributes software packages down a distribution hierarchy. Each distribution server has a basic object type which is extended with several facets. The Packages facet details which packages are or should be on each server. The Hierarchy facet details where this server lives in the hierarchy, and the Configuration facet details the configuration state of each server. These facets are *independent* of each other, yet belong to the same object - each reflects where the object cuts across a particular aspect. It's a kind of polymorphism, so not really that new. I think that the use of Aspect Oriented techniques beyond the infrastructure layers is the main area for adding value. As has been noted, infrastructure requirements should be built into the basic language, or added through low-impact libraries - Ruby allows (though by manual construction) the best of both worlds in this regard. We are using Ruby for a multiple tier generator based on an XML database schema language. This generator makes use of Ruby's mixins and the "extend" method to implement "facet realisation" - dynamic extension of base classes to allow them to serve in a particular context. This is primitive aspect oriented programming, and works well. The generator produces data tiers in C# and C++, web services definitions and implementations, web-service client proxy stubs that implement location- and version-transparency, as well as high-quality printed documentation, SQL DDL and stored procedures, and will be extended to cover test cases, schema migration and perhaps user interfaces (in C#). Despite our database only containing 58 tables, the 3KLOC generator reads a 1.2KLOC schema file and generates over 50KL of high-quality, formatted, readable, commented code. If I was a contractor it would be a license to print money. Of all langages I've learnt or created, implementing this generator in Ruby using aspect-oriented techniques is the only way to have kept it down to its current 3KLOC - and most of that code is templates! > Is it the fact that AOP is new and, for most, confusing Maybe. Although it is somewhat difficult to grapple with, the intrinsic concepts are much simpler than current implementations indicate. AspectJ had to integrate with Java, so had to multiply the basic concepts, and had to live within the traditional source-file idiom. AOD tools *must* support dynamic view synthesis, allowing visualisation of the system in both composed and partly-composed form. I'm not aware of a tool that does that. Aspect oriented design requires a visual language for presenting designs. Some work has been done on adding AOD features to UML, but basically it's difficult because AOD is used to implement multi-dimensional designs - which can't easily be flattened to any 2-D language. I think that the only hope there is for a 1-D (traditional text-based) language which is supported by powerful graphical tools which allow filtering the aspects exposed in dynamic views. A true AOD language (as opposed to a hack preprocessor added to an existing language) would also support dynamic extension (which I term facet realisation). We do that in Ruby with mixins and extend(), but it's a bit too "manual". > Is an Open Source development ever going to gain the trust of industry? What on earth has that got to do with AOP? > What are the main features that may lead to AOSD adoption? Proper filtering aspect browsers in an IDE for a naturally aspect-oriented language. None of which currently exist, as far as I'm aware. > Is AOP the next step on from OOP? Perhaps, if the tool support is provided. > Is it another chance for some of the lesser > utilised languages to step up to Java and C++? No. I don't believe that AOD can be adequately justified when implemented as an extension to either C++ or Java. AFAIK, there is no viable candidate for the title of the first viable aspect-oriented language. I meant to publish a bunch of writings and tools at my nascent domain www.aspectdesign.org, but my employer is not forthcoming with an IP disclaimer to publish tools so the domain lies dormant and the tools unwritten. Sigh. I honestly believe these tools must be open source. I've previously tried to found a business based on simple, general powerful software tools and languages, and have become convinced that commercial survival is only possible with limited-purpose tools. Proprietry standards for basic technologies are doomed. Clifford Heath, cjh at spam-me-rotten.managesoft.com - you work it out.