Aspect-Oriented Programming

Aspect-Oriented Programming

[Richard Riehle]

I was having a conversation last week with a colleague
and the topic turned to aspect-oriented programming.  This
rather interesting approach to software design seems, at first,
to break encapsulation, but close inspection, offers some
powerful capabilities for reuse and corresponds to the reality
of a physical world architectures.

As we talked, I realized that there was an opportunity to
consider the role of private child packages in the design of
aspect-oriented architectures.    So I am wondering if anyone
in this forum has investigated the unique properties of Ada
that contribute to aspect-oriented software architectures.

Richard Riehle

Re: Aspect-Oriented Programming

[Nick Roberts]

On Sun, 29 Sep 2002 12:46:30 -0700, Richard Riehle <richard@adaworks.com>
strongly typed:

>I was having a conversation last week with a colleague
>and the topic turned to aspect-oriented programming.  This
>rather interesting approach to software design seems, at first,
>to break encapsulation, but close inspection, offers some
>powerful capabilities for reuse and corresponds to the reality
>of a physical world architectures.
>
>As we talked, I realized that there was an opportunity to
>consider the role of private child packages in the design of
>aspect-oriented architectures.    So I am wondering if anyone
>in this forum has investigated the unique properties of Ada
>that contribute to aspect-oriented software architectures.

Forgive me for reposting an article I posted here in February, in a thread
about refactoring, complete with brain-damage warning (which still
applies).

==========

[ *** WARNING: mind-numbing esoterica follows; no liability for brain
damage can be accepted. *** ]

If you would like me to throw in my own ideas, one fairly elaborate one
occurs to me, to do with providing support for Aspect-Oriented Programming
in Ada. It would work something like as follows.

First, the user specifies a list A of aspects, each having a name N (which
is a valid Ada name). One of these aspects is designated the default Nd.
Each name would either be simple (an identifier) or compound (having a
prefix). The operation is applied to a library package P, and does the
following:

(1) for each (N) of all the aspects in A, write a new private package
specification named P.N, containing an inlined declaration for each
subprogram S declared in the specification of P, each such declaration
being a copy of the declaration of S but excluding out-mode parameters in
the case of the default aspect, and a procedure in all other cases with the
same parameters but excluding the out-mode (and return) parameters;

(2) rewrite the existing body of P with the name P.Nd (but otherwise
unchanged);

(3) for each (N) of the other aspects in A, write a new body named P.N,
which contains a null completion for each subprogram in the specification
of P;

(4) write a new body of P, with a completion for each subprogram in the
specification of P, each such completion containing (only) a call to each
member (N) of A (in the order given) in the form "P.N(parameters)" where
the parameters are a repetition of the formal parameters of the subprogram,
and the result of a function is held in a temporary and returned at the
end, if necessary.

In addition, for each member of the set formed by the closure of the
ancestors of the (compound) names of A, write out an empty private package
specification.

An example might illuminate the idea. Suppose we have a package:

   with Customers;
   package Ice_Cream is
      type Cone is private;
      function Make return Cone;
      procedure Eat (Item:   in out Cone;
                     Person: in out Customers.Human);
   private
      ... private stuff
   end Ice_Cream;

   package body Ice_Cream is

      function Make return Cone is
      begin
         ... make a cone
      end;

      procedure Eat (Item:   in out Cone;
                     Person: in out Customers.Human) is
      begin
         ... eat a cone
      end;

   end Ice_Cream;

Now, suppose we wished to divide this into the aspects: Debug.Before; Main;
Debug.After. The refactoring would generate the following compilation
units:

   private package Ice_Cream.Debug is end;

   private package Ice_Cream.Debug.Before is
      procedure Make;
      procedure Eat (Item:   in out Cone;
                     Person: in out Customers.Human);
      pragma Inline(Make,Eat);
   end Ice_Cream.Debug.Before;

   private package Ice_Cream.Main is
      function Make return Cone;
      procedure Eat (Item:   in out Cone;
                     Person: in out Customers.Human);
      pragma Inline(Make,Eat);
   end Ice_Cream.Main;

   private package body Ice_Cream.Debug.After is
      procedure Make;
      procedure Eat (Item:   in out Cone;
                     Person: in out Customers.Human);
      pragma Inline(Make,Eat);
   end Ice_Cream.Debug.After;

   package body Ice_Cream.Debug.Before is

      procedure Make is
      begin
         null;
      end;

      procedure Eat (Item:   in out Cone;
                     Person: in out Customers.Human) is
      begin
         null;
      end;

   end Ice_Cream.Debug.Before;

   package body Ice_Cream.Main is

      function Make return Cone is
      begin
         ... make a cone
      end;

      procedure Eat (Item:   in out Cone;
                     Person: in out Customers.Human) is
      begin
         ... eat a cone
      end;

   end Ice_Cream.Main;

   package body Ice_Cream.Debug.After is

      procedure Make is
      begin
         null;
      end;

      procedure Eat (Item:   in out Cone;
                     Person: in out Customers.Human) is
      begin
         null;
      end;

   end Ice_Cream.Debug.After;

The following replacement compilation unit would be generated:

   package body Ice_Cream is

      function Make return Cone is
         Temp: Cone;
      begin
         Ice_Cream.Debug.Before.Make;
         Temp := Ice_Cream.Main.Make;
         Ice_Cream.Debug.After.Make;
         return Temp;
      end;

      procedure Eat (Item:   in out Cone;
                     Person: in out Customers.Human) is
      begin
         Ice_Cream.Debug.Before.Eat(Item,Person);
         Ice_Cream.Main.Eat(Item,Person);
         Ice_Cream.Debug.After.Eat(Item,Person);
      end;

   end Ice_Cream.Main;

For any other compilation unit written, if the unit already exists, it is
not replaced.

Obviously, the idea is to automatically generate a skeleton that provides
for the separation of the implementation of a library package into a set of
different aspects.

It also would be good to have operations that: added aspects to an
implementation already divided; coalesced several aspects back into one;
coalesced all the aspects back into one body.

I'm sure that any number of similarly specialised and elaborate
refactorings could be useful to some people. I'm also sure that useful
manipulations would not be limited to those which preserve (external)
semantics.

==========

The thread got a bit sidetracked (it included some comments by Richard on a
different topic). Hope you don't mind. As you get older you start repeating
yourself.

Never mind, as they say: as you get older you start ... um, did I just say
that?

-- 
Nick Roberts
Per Ardua ad Disastra

Re: Aspect-Oriented Programming

[Pat Rogers]

"Nick Roberts" <nickroberts@blueyonder.co.uk> wrote in message
news:3d977d7e.65439093@news.cis.dfn.de...
> On Sun, 29 Sep 2002 12:46:30 -0700, Richard Riehle
<richard@adaworks.com>
> strongly typed:
>
> >I was having a conversation last week with a colleague
> >and the topic turned to aspect-oriented programming.  This
> >rather interesting approach to software design seems, at first,
> >to break encapsulation, but close inspection, offers some
> >powerful capabilities for reuse and corresponds to the reality
> >of a physical world architectures.
> >
> >As we talked, I realized that there was an opportunity to
> >consider the role of private child packages in the design of
> >aspect-oriented architectures.    So I am wondering if anyone
> >in this forum has investigated the unique properties of Ada
> >that contribute to aspect-oriented software architectures.

I have just started looking at AOP.  See below for why.

> If you would like me to throw in my own ideas, one fairly elaborate
one
> occurs to me, to do with providing support for Aspect-Oriented
Programming
> in Ada. It would work something like as follows.
<snip>

What you want looks like the product of compile-time reflection.  As
far as I understand it so far, reflection is an enabling technology
for AOP.   I have seen papers using compile-time reflection
(specifically, OpenC++) for AOP.

I have an "reasonably complete" implementation of compile-time
reflection similar to OpenC++ for Ada 95 (named OpenAda) that I will
make available some day...

--
Patrick Rogers                       Consulting and Training in:
http://www.classwide.com       Real-Time/OO Languages
progers@classwide.com          Hard Deadline Schedulability Analysis
(281)648-3165                            Software Fault Tolerance

Re: Aspect-Oriented Programming

[Caffeine Junky]

On Sun, 29 Sep 2002 15:46:30 -0400, Richard Riehle wrote:

> I was having a conversation last week with a colleague and the topic
> turned to aspect-oriented programming.  This rather interesting approach
> to software design seems, at first, to break encapsulation, but close
> inspection, offers some powerful capabilities for reuse and corresponds
> to the reality of a physical world architectures.
> 
> As we talked, I realized that there was an opportunity to consider the
> role of private child packages in the design of aspect-oriented
> architectures.    So I am wondering if anyone in this forum has
> investigated the unique properties of Ada that contribute to
> aspect-oriented software architectures.
> 
> Richard Riehle
 
I beleive the October or September issues of Dr. Dobbs Journal did a
feature article on AOP in reference to Java.
I've got the mag in my rack here. Havent had a chance to read the article
yet.

Sounds interesting though. Sounds like a useful approach for some Ada
projects as well.

NiCad

Re: Aspect-Oriented Programming

[Richard Riehle]

Nick Roberts wrote:

> Forgive me for reposting an article I posted here in February, in a thread
> about refactoring, complete with brain-damage warning (which still
> applies).

Forgiveness unnecessary.   I am delighted to see that you and I
are on pretty much the same track here.   As I see it, Ada has
a lot to offer for AO and, with private child units, the ability
to preserve encapsulation while enabling "cross-cutting" of
aspects.

Dr. Jean-Pierre Rosen tells me that this is a topic of interest
at the next Ada Europe conference in Toulouse.   Perhaps
some additional research and experimentation is in order.
Also, this would be a great paper to submit to OOPSLA, it
it can be submitted in time for the Oct 15 deadline.

If you can have a paper proposal ready by Oct 15, send it
to Haim Kilov whose email address is  haimk@acm.org
for possible acceptance at OOPSLA.

While I'm at it, Haim is pretty generous about OOP
in Ada and will be open to paper proposals in which
Ada is used to illustrate some new or advanced idea
in object technology.

Richard Riehle

Re: Aspect-Oriented Programming

[Nick Roberts]

On Tue, 01 Oct 2002 16:45:02 -0700, Richard Riehle <richard@adaworks.com>
strongly typed:

>...
>Dr. Jean-Pierre Rosen tells me that this is a topic of interest
>at the next Ada Europe conference in Toulouse.   Perhaps
>some additional research and experimentation is in order.
>Also, this would be a great paper to submit to OOPSLA, it
>it can be submitted in time for the Oct 15 deadline.
>
>If you can have a paper proposal ready by Oct 15, send it
>to Haim Kilov whose email address is  haimk@acm.org
>for possible acceptance at OOPSLA.

I shall try to fit it into my busy schedule.


-- 
Nick Roberts
Per Ardua ad Disastra

Re: Aspect-Oriented Programming

[Programmer Dude]

Nick Roberts wrote:

I was very interested in your example of AOP.  I puzzled over this:

> Now, suppose we wished to divide this into the aspects: Debug.Before;
> Main; Debug.After. The refactoring would generate the following
> compilation units:
> 
>    private package Ice_Cream.Debug is end;
>    private package Ice_Cream.Debug.Before is
>        [...]
>    end Ice_Cream.Debug.Before;
> 
>    private package Ice_Cream.Main is
>        [...]
>    end Ice_Cream.Main;
> 
>    private package body Ice_Cream.Debug.After is
>        [...]
>    end Ice_Cream.Debug.After;

Should the keyword "body" not be there above?  (I have, so far, only
a smattering, passing knowledge of Ada, so I'm probably wrong.)

In any event, I found it a very educational example; thanks!

-- 
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL  |
|_____________________________________________|_______________________|



Opinions expressed herein are my own and may not represent those of my employer.

Re: Aspect-Oriented Programming

[Jim Rogers]

Programmer Dude wrote:

> Nick Roberts wrote:
> 
> I was very interested in your example of AOP.  I puzzled over this:
> 
> 
>>Now, suppose we wished to divide this into the aspects: Debug.Before;
>>Main; Debug.After. The refactoring would generate the following
>>compilation units:
>>
>>   private package Ice_Cream.Debug is end;
>>   private package Ice_Cream.Debug.Before is
>>       [...]
>>   end Ice_Cream.Debug.Before;
>>
>>   private package Ice_Cream.Main is
>>       [...]
>>   end Ice_Cream.Main;
>>
>>   private package body Ice_Cream.Debug.After is
>>       [...]
>>   end Ice_Cream.Debug.After;
>>
> 
> Should the keyword "body" not be there above?  (I have, so far, only
> a smattering, passing knowledge of Ada, so I'm probably wrong.)
> 
> In any event, I found it a very educational example; thanks!
>


These are private package specifications. As such they must not
have the word "body" as part of their declaration line. The private
bodies would have the word "body".

Jim Rogers

Re: Aspect-Oriented Programming

[Programmer Dude]

Jim Rogers wrote:

>>>   private package body Ice_Cream.Debug.After is
>>>       [...]
>>>   end Ice_Cream.Debug.After;
>>>
>>
>> Should the keyword "body" not be there above?  (I have, so far, only
>> a smattering, passing knowledge of Ada, so I'm probably wrong.)
>>
>> In any event, I found it a very educational example; thanks!
> 
> These are private package specifications. As such they must not
> have the word "body" as part of their declaration line. The private
> bodies would have the word "body".

Cool!  I just debugged my first Ada program!!  ;-)

-- 
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL  |
|_____________________________________________|_______________________|



Opinions expressed herein are my own and may not represent those of my employer.