<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<p>Thorsten Dittmar wrote:
<br>
<p><i>For example, Self has mixins and dynamic inheritance with this two</i>
<br><i>mechanisms you can solve a lot of the AOP stuff.</i>
<br>
<p>In 1988, I had to start implementing my ecodesign model. I immediately
realize
<br>that OO programming would fit my needs (despite the fact that no computer
<br>scientist in Brazil had apparently heard of it -- in 1990 everybody
was aware
<br>of C++!!!). Then I had lots of problems because I have parallel, crosscutting
<br>and composition of concerns in my ecodesign model.
<br>Each new OO programming language that would appear I would exam to
check
<br>if it would fit my needs. C++, Simula, Eiffel, Sather, CLOS.
<br>This sounded good! Well then I had to develop a Blackboard Architecture
to
<br>implement my ecodesign model (1992)
<br>In the meantime I heard of BETA, according to Jecel it is obviously
the first
<br>prototype based language. I liked everything there especially concurrency.
<br>Then I made up my mind it was OK! With the time being I realized it
was
<br>not exactly possible to program in it in a bottom up way! Or in an
hermeneutic
<br>way or like a conversation simulating the way a sustainable building
unfolds.
<br>Then I heard of Self.
<p>I am very happy with Self! Then I thought mixins in Self would help
me to
<br>implement the crosscutting concerns of my ecodesign model. I started
<br>my postdoctorate studies with this in mind!
<p>I read The programming language Jigsaw: mixins, modularity and
<br>multiple inheritance. This story of modularity did not make me happy!
<p>Then I started studying reflection!
<br>Finally I found MDSOC, US, AOSD and so on!!!!
<p>It is a BAbel effect !
<p>I have taken the liberty to quote these discussions from AOSD list:
<br>The discussion started with this question:
<pre> > From: Wesley C. Virnelson [wvirnelson@yahoo.com]
> > Subject: [aosd-discuss] Multiple inheritance
> >
> > <i>Wouldn't this whole crosscutting problem go away if Java
> allowed multiple
> > iheritance?
></i></pre>
<pre><i></i></pre>
<pre><i>Then the </i>answer:</pre>
<pre>From: discuss-admin@aosd.net [<A HREF="mailto:discuss-admin@aosd.net">mailto:discuss-admin@aosd.net</A>]On Behalf Of
> L Carver
> Sent: Monday, July 01, 2002 11:04 AM
> To: discuss@aosd.net
> Cc: wvirnelson@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.
> ---
> <A HREF="http://www.pnambic.com/leeca">http://www.pnambic.com/leeca</A>
> ... The real cycle you're working on is a cycle called 'yourself'.</pre>
<p>
<p>-----Ursprungligt meddelande-----<br>
Från: Alan Moore [<A HREF="mailto:alan@closedsource.com">mailto:alan@closedsource.com</A>]<br>
Skickat: den 2 juli 2002 09:11<br>
Till: discuss@aosd.net<br>
Ämne: RE: [aosd-discuss] Multiple inheritance<br>
<br>
<br>
If you consider the case of two (or more) classes all of which multiply<br>
inherit from a common aspect class to be crosscutting then MI in Java might<br>
get you something.<br>
<br>
Aspectj goes beyond derivation semantics by supporting crosscutting based
on<br>
various meta-data/signatures the ajc compiler knows about your code base.<br>
<br>
The well known join points such as constructors, method calls, etc. are
a<br>
start and could be emulated using derivation (I think ajc might use a<br>
related implementation technique) but this seems to be only half the story<br>
and the aspectj language is not limited in this respect.<br>
<br>
The pattern matching in aspectj gives it a degree of freedom derivation<br>
cannot.<br>
<br>
see:<br>
<A HREF="http://aspectj.org/doc/dist/progguide/apb.html#d0e4077">http://aspectj.org/doc/dist/progguide/apb.html#d0e4077</A><br>
<br>
alan<br>
________________________________________________<br>
"Over himself, over his own mind and body,<br>
the individual is sovereign." - John Stuart Mill.<br>
<br>
<br>
> -----Original Message-----<br>
> From: discuss-admin@aosd.net [<A HREF="mailto:discuss-admin@aosd.net">mailto:discuss-admin@aosd.net</A>]On Behalf
Of<br>
> L Carver<br>
> Sent: Monday, July 01, 2002 11:04 AM<br>
> To: discuss@aosd.net<br>
> Cc: wvirnelson@yahoo.com<br>
> Subject: RE: [aosd-discuss] Multiple inheritance<br>
><br>
><br>
> No. Very often an aspect's complete implementation will require<br>
> changes to<br>
> multiple classes. No amount of multiple inheritance in a single<br>
> class will<br>
> support coordinated changes to multiple classes.<br>
> ---
<blockquote TYPE=CITE>
<pre>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
</pre>
</blockquote>
<blockquote TYPE=CITE><br>
<br>
<br>
<br>
>From a decompiled ajc-compiled class:<br>
<br>
...<br>
<br>
public Call call(Customer receiver)<br>
{<br>
Call call = new Call(this, receiver);<br>
addCall$method_call(this, call);
// This line is added by the ajc<br>
return call;<br>
}<br>
<br>
...<br>
<br>
/** ajc-generated method that receives the call above, <br>
generates reflective access to the joinpoint and performs advice code by
calling another<br>
generated method (around28_addCall$method_call), <br>
which implements advice from an "around" statement in an aspect.*/<br>
<br>
private void addCall$method_call(Customer target, Call
c)<br>
throws Error<br>
{<br>
JoinPoint thisJoinPoint = Factory.makeJP(addCall$ajcjp1,
this, target, new Object[] {<br>
c<br>
});<br>
Logging.cflow$ajc0.push(new
CFlow());<br>
try<br>
{<br>
<br>
// In the method below, the "around" advice code is found<br>
<br>
around28_addCall$method_call(null,
thisJoinPoint, Logging.aspectInstance, target, c); <br>
}<br>
catch(Error ajcexc$27)<br>
{<br>
if(!Logging.cflow$ajc0.isValid())<br>
Logging.aspectInstance.afterThrowing0$ajc(ajcexc$27);<br>
throw
ajcexc$27;<br>
}<br>
finally<br>
{<br>
Logging.cflow$ajc0.pop();<br>
}<br>
}<br>
Well I continued puzzled by the Babel Effect and then finally I met recent
Jörg Kienzle's recent PHD thesis about</blockquote>
concurrency. He also wrote a paper Does aspect oriented programmming make
sense? for last ECOOP'02!You
<br>can download this on site:
<p><A HREF="http://lglwww.epfl.ch/~jkienzle/">http://lglwww.epfl.ch/~jkienzle/</A>
<p>Then he shyly tries to show that nonfunctional aspects like concurrency
are part of the functional aspect.
<br>In this case especially when you add more semantics to the analysis
of concurrency, AOP may not
<br>make sense!
<p>I am delighted because KIenzle's PHD thesis and paper is what I call
a CLEAR BOX! Everything is
<br>evident there even for artists like me!!!!A far cry from all this writing
about aspects and nonfunctional
<br>aspects.Everything is palatable there, even ASPECT J implementation!
<p>And in this context it is possible to perceive how the introduction
of musical chords may really
<br>contribute to devise a morphodynamic level in computer science.
SEmioticians like Petitot Cocorda
<br>working with René Thom strive to show the topologization of
concepts!
<p>How and where SElf enter in this story?
<p>Sharing is weaving. And according to Daniel Bardou this can be done
gracefully in prototype-
<br>based languages. My main difficulty is how can I introduce constructs
in Self, I mean in
<br>the context of prototypes that will enable me simulate the talkative
nature of my ecodesign model?
<p>Or something like a better AOSD?
<p>Having studied the Mjolner BETA system I realized how I could add constructs.
But
<br>I really cannot understand the environmental system where SElf is embedded!
<p>AS I said, the way Jörg Kienzle reasons it is very easy to understand
everything about
<br>concurrency control, recovery, fault tolerance, logging, caching everything!
I would
<br>like to read something similar about Self! Then I would know how to
introduce
<br>the necessary constructs that would mimic a better AOSD!
<p>Any contribution is welcome!
<br>Albertina
<br>
<br>
<blockquote TYPE=CITE><br>
<BR></blockquote>
</html>