[self-interest] Aspect oriented and self

Wed Aug 21 18:08:20 UTC 2002

Thorsten Dittmar wrote:

For example, Self has mixins and dynamic inheritance with this two
mechanisms you can solve a lot of the AOP stuff.

In 1988, I had to start implementing my ecodesign model. I immediately realize
that OO programming would fit my needs (despite the fact that no computer
scientist in Brazil had apparently heard of it -- in 1990 everybody was aware
of C++!!!). Then I had lots of problems because I have parallel, crosscutting
and composition of concerns in my ecodesign model.
Each new OO programming language that would appear I would exam to check
if it would fit my needs. C++, Simula, Eiffel, Sather, CLOS.
This sounded good! Well then I had to develop a Blackboard Architecture to
implement my ecodesign model (1992)
In the meantime I heard of BETA, according to Jecel it is obviously the first
prototype based language. I liked everything there especially concurrency.
Then I made up my mind it was OK! With the time being I realized it was
not exactly possible to program in it in a bottom up way! Or in an hermeneutic
way or like a conversation simulating the way a sustainable building unfolds.
Then I heard of Self.

I am very happy with Self! Then I thought mixins in Self would help me to
implement the crosscutting concerns of my ecodesign model. I started
my postdoctorate studies with this in mind!

I read  The programming language Jigsaw: mixins, modularity and
multiple inheritance. This story of modularity did not make me happy!

Then I started studying reflection!
Finally I found MDSOC, US, AOSD and so on!!!!

It is a BAbel effect !

I have taken the liberty to quote these discussions from AOSD list:
The discussion started with this question:

 > From: Wesley C. Virnelson [wvirnelson at yahoo.com]
> > Subject: [aosd-discuss] Multiple inheritance
> >
> > Wouldn't this whole crosscutting problem go away if Java
> allowed multiple
> > iheritance?
>

Then the answer:

From: discuss-admin at aosd.net [mailto:discuss-admin at aosd.net]On Behalf Of
> L Carver
> Sent: Monday, July 01, 2002 11:04 AM
> To: discuss at aosd.net
> Cc: wvirnelson at yahoo.com
> Subject: RE: [aosd-discuss] Multiple inheritance
>
>
> No.  Very often an aspect's complete implementation will require
> changes to
> multiple classes.  No amount of multiple inheritance in a single
> class will
> support coordinated changes to multiple classes.
> ---
> http://www.pnambic.com/leeca
> ... The real cycle you're working on is a cycle called 'yourself'.

-----Ursprungligt meddelande-----
Från: Alan Moore [mailto:alan at closedsource.com]
Skickat: den 2 juli 2002 09:11
Till: discuss at aosd.net
Ämne: RE: [aosd-discuss] Multiple inheritance

If you consider the case of two (or more) classes all of which multiply
inherit from a common aspect class to be crosscutting then MI in Java might
get you something.

Aspectj goes beyond derivation semantics by supporting crosscutting based on
various meta-data/signatures the ajc compiler knows about your code base.

The well known join points such as constructors, method calls, etc. are a
start and could be emulated using derivation (I think ajc might use a
related implementation technique) but this seems to be only half the story
and the aspectj language is not limited in this respect.

The pattern matching in aspectj gives it a degree of freedom derivation
cannot.

see:
http://aspectj.org/doc/dist/progguide/apb.html#d0e4077

alan
________________________________________________
"Over himself, over his own mind and body,
the individual is sovereign." - John Stuart Mill.

> -----Original Message-----
> From: discuss-admin at aosd.net [mailto:discuss-admin at aosd.net]On Behalf Of
> L Carver
> Sent: Monday, July 01, 2002 11:04 AM
> To: discuss at aosd.net
> Cc: wvirnelson at yahoo.com
> Subject: RE: [aosd-discuss] Multiple inheritance
>
>
> No.  Very often an aspect's complete implementation will require
> changes to
> multiple classes.  No amount of multiple inheritance in a single
> class will
> support coordinated changes to multiple classes.
> ---

> Hi,
>
> IMHO "real" multiple inheritance in Java would not get you the same thing that AOP does. I think AOP is much better.
>
> You can ofcourse use MI to add lots of cross-cutting functionality to a class, but you cannot (easily) dynamically add or remove MI functionality without altering the code of the class. For instance Tracing or Debug logging. I would not want that to be inherited and then have log statements all over my classes.
>
> If you could use MI, and still wanted to avoid code bloating and tangling:H
>  ow would you go about to dynamically change it so that, for instance, after each method call in class Foo, call another method from the inherited class Bar?
>
> You'd have to use dynamic proxies (or some trick of your own), with some set of meta-rules describing what inherited methods to call, and then you're pretty much doing AOP anyway.
>
> Also, "real" MI is an additional complexity that is not needed when you have AOP. Simple is good.
>
> On a side note to Alan; AFAIK the ajc generates new Java methods in the affected class to intercept calls (act as pointcuts) and can then perform the advice code or the origin method. An example below.
>
> Yours,
> Magnus
>
>
>
>
>
>
> >From a decompiled ajc-compiled class:
>
> ...
>
> public Call call(Customer receiver)
>     {
>         Call call = new Call(this, receiver);
>         addCall$method_call(this, call);  // This line is added by the ajc
>         return call;
>     }
>
> ...
>
> /** ajc-generated method that receives the call above,
> generates reflective access to the joinpoint and performs advice code by calling
> another
> generated method (around28_addCall$method_call),
> which implements advice from an "around" statement in an aspect.*/
>
>     private void addCall$method_call(Customer target, Call c)
>         throws Error
>     {
>         JoinPoint thisJoinPoint = Factory.makeJP(addCall$ajcjp1, this, target, new
> Object[] {
>             c
>         });
>         Logging.cflow$ajc0.push(new CFlow());
>         try
>         {
>
> // In the method below, the "around" advice code is found
>
>             around28_addCall$method_call(null, thisJoinPoint,
> Logging.aspectInstance, target, c);
>         }
>         catch(Error ajcexc$27)
>         {
>             if(!Logging.cflow$ajc0.isValid())
>                 Logging.aspectInstance.afterThrowing0$ajc(ajcexc$27);
>             throw ajcexc$27;
>         }
>         finally
>         {
>             Logging.cflow$ajc0.pop();
>         }
>     }
> Well I continued puzzled by the Babel Effect and then finally I met recent Jörg
> Kienzle's recent PHD thesis about

concurrency. He also wrote a paper Does aspect oriented programmming make sense? for
last ECOOP'02!You
can download this on site:

http://lglwww.epfl.ch/~jkienzle/

Then he shyly tries to show that nonfunctional aspects like concurrency are part of
the functional aspect.
In this case especially when you add more semantics to the analysis of concurrency,
AOP may not
make sense!

I am delighted because KIenzle's PHD thesis and paper is what I call a CLEAR BOX!
Everything is
evident there even for artists like me!!!!A far cry from all this writing about
aspects and nonfunctional
aspects.Everything is palatable there, even ASPECT J implementation!

And in this context it is possible to perceive how the introduction of musical
chords may really
contribute to devise  a morphodynamic level in computer science. SEmioticians like
Petitot Cocorda
working with René Thom strive to show the topologization of concepts!

How and where SElf enter in this story?

Sharing is weaving. And according to Daniel Bardou this can be done gracefully in
prototype-
based languages.  My main difficulty is how can I introduce constructs in Self, I
mean in
the context of prototypes that will enable me simulate the talkative nature of my
ecodesign model?

Or something like a better AOSD?

Having studied the Mjolner BETA system I realized how I could add constructs. But
I really cannot understand the environmental system where SElf is embedded!

AS I said, the way Jörg Kienzle reasons it is very easy to understand everything
about
concurrency control, recovery, fault tolerance, logging, caching everything! I would

like to read something similar about Self! Then I would know how to introduce
the necessary constructs that would mimic a better AOSD!

Any contribution is welcome!
Albertina

>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.selflanguage.org/pipermail/self-interest/attachments/20020821/4cced67e/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lourenci.vcf
Type: text/x-vcard
Size: 316 bytes
Desc: Card for Albertina Lourenci
URL: <http://lists.selflanguage.org/pipermail/self-interest/attachments/20020821/4cced67e/attachment.vcf>