[aosd-discuss] Non academic ideas on AOSD
denisbilas at yandex.ru
Thu Oct 17 01:32:36 EDT 2002
Thanks for the reply -- it was very interesting! Since you aggressively promote Cosmos as means to solve the problems touched in the thread, I think I need some more time to have a deeper look at the thing. It would be very helpful (hope not only for me) if you point out an online place to start reading about Cosmos.
> -----Original Message-----
> From: Juri Memmert [mailto:jadawinarc at yahoo.com]
> Sent: Wednesday, October 16, 2002 6:49 PM
> To: aosd
> Subject: RE: [aosd-discuss] Non academic ideas on AOSD
> --- Denis Bilas <denisbilas at yandex.ru> wrote:
> Hi Denis,
> > > -----Original Message-----
> > > From: Juri Memmert [mailto:jadawinarc at yahoo.com]
> > >
> > > I consider the ability to incorporate unanticipated
> change cleanly and
> > > relatively effortlessly a major capability and advantage, but
> > > it's not the only
> > > one...
> > Yes, but IMHO cleanness is MUCH MUCH more important than relative
> > effortlessness. The less a change is clear, the more it is
> likely to incur
> > significant (or even critical) overhead to all subsequent work. This
> > statement is the key to the entire idea I described in my post.
> Yes. I concur. I was merely paraphrasing your post.
> > > 1) Defining the join point
> > > This can be a problem... Most often, it is a problem because
> > > the exact join
> > > point can not be easily determined from the code alone. There are
> > > considerations at work which go beyond the code... which is
> > > why a "mere"
> > > code-level tool must fail (or have a very hard time).
> > 100% agree. And I think the best known solution is to
> capture and use the
> > design information about the code being changed.
> That's what I do with Cosmos.
> > > 2) Applying multiple aspects to the same join point
> > > Again, this is indeed a problem... if you do not offer
> support on the
> > > architectural, requirements, analysis and design level.
> > > If you use [insert your favorite AOP tool here], you're
> > > going to be in
> > > trouble.
> > > If you use a global approach that captures the complexity
> > > where it arises and
> > > where it can be solved (and that's often not the code level),
> > > much of the
> > > perceived complexity at the code level vanishes.
> > Yes, that's true. And all we need is a tool that helps to
> make a change
> > cleanly (!) and with sensible amount of effort.
> Can I hear someone say: "He's going to say 'Cosmos' now?" ;-)
> > > > I suggest that we don't strive for
> > > > perfectness. It looks like AOP wants to
> > > > help the team implement some unanticipated
> > > > crosscutting change instantly,
> > > > with zero rework, and so on. But this is
> > > > hardly achievable at this stage of
> > > > the technology, WHILE in fact the team would
> > > > be quite happy if such
> > >
> > > Sorry... This may be true for AspectJ (and I doubt that
> > > you'll find many that
> > > concur with your estimate), but my experience with Hyper/J
> > > tells me that your
> > > statement is wrong.
> > Well what I said was taken from the usual buzz around AOP.
> I didn't mean
> > AspectJ or Hyper/J or any other tool. I meant the core
> ideas of AOP as they
> > are often (sometimes?) presented.
> Misrepresented. There is no free lunch, after all... ;-)
> > > I've been dealing with unanticipated changes, crosscutting,
> > > broken contracts
> > > and that stuff within the context of AOSD for almost
> three years now.
> > > I have performed many projects where the "instant" [see
> > > clarification below]
> > > implementation of an unanticipated crosscutting change was
> > > needed... and it was
> > > easily achievable...
> > Instant change often results in troubles when other instant
> or non-instant
> > changes are applied afterwards and unanticipated and
> untraceable interference
> > occurs. But yes, sometimes instant change is what we need
> -- if we do not
> > plan to support this particular stream of code.
> "Instant" was meant in the context of my comments further
> down... In good code,
> there is no "instant".
> > > ..... in
> > > Hyper/J means that (unless you're dealing with a completely
> > > new function) you
> > > should remodularize the application to different hyperslices
> > > pertaining to the
> > > different concerns, manipulate the affected hyperslices, test
> > > them separately,
> > > merge them, do integration tests, and so forth.
> > I agree -- this is the way to go. On the other note, does
> not this require
> > having the source code (referring to your comments below) ?
> No. Source is not needed. I hardly am allowed to touch the
> source in many of
> the firebrigade projects I am working on. And I have found
> that is is rarely
> needed unless the documentation is crappy, of course).
> > > This whole thing is not about "instant gratification". It
> > > could be done but
> > > would lead to problems lateron... like an hack.
> > > So, the Hyper/J approach (and I am sure that Arno will say
> > > something similar
> > > for AspectJ) is not about zero rework but about a
> > > "considerable, yet bounded,
> > > amount of effort" and does not "lead to tangled code". So, at
> > > least from my
> > > experience, the current state of AOSD tools allows these
> > > benedfits already.
> > Ok, I do agree on the approach. But I'm not yet sure that
> Hyper/J is the idea
> > tool for that. I studied it and know the basic concept, but
> not an expert in
> > the field, so my perception may be wrong. I cannot even
> prove it, and I think
> > it cannot be proven on simple examples -- a large project
> must be considered!
> Hmmm... my scientific mind is sent reeling when I hear that...
> Well... from my experience in large projects employing
> Hyper/J, I can only say
> that it can be done.
> > The time will show... But from what I can say now, I feel
> that an "ideal"
> > tool must deal with extending the share of design
> information in code.
> Cosmos + Hyper/J
> They're based on the same concepts, so the transfer of
> knowledge is simple and
> they cover the whole developmen process, including design information.
> > > So you assume that you have the source and that you're
> > > allowed to change it?
> > I do -- at this stage.
> Lucky you. This is not common.
> > > > The "design" construct here helps to identify join points.
> > > The stuff inside
> > > > the parenthesis is an arbitrary sequence -- another idea is
> > > to use mechanism
> > > > that resembles attributes in C#.
> > >
> > > So you want to change base code... change code that knows
> > > nothing about AOSD
> > > into some AOSD aware structure, forcing AOP constructs on the
> > > developer that
> > > wrote the class?
> > Not exactly. The developer that writes the class is not
> forced to make it
> > AOP-aware. Instead, the requirement is to capture and store
> additional design
> > information about the code when it is needed. It's
> impossible to capture all
> > the design information, but possible to capture certain
> statements that are
> > important in a particular situation -- so that's why the
> "design" keyword.
> Where shall this additional design information be stored?
> Within the original
> class? Then my comment about maintainability applies (see
> comment below).
> Outside of the class? That's what can be done with Cosmos.
> So... yes... this is needed. No, this is not needed _within_
> the class.
> > > Because, in the end, you either have to maintain the change
> > > for each and every
> > > new version of each and every class you manipulate that the
> > > original developer
> > > finishes or you have to force the developer to learn AOP.
> > I'm not sure. I think not, since the class developer only
> have to add the
> > required design information, without worrying how it's
> going to be used.
> The developer needs to add a keyword to the class that can
> not be compiled in a
> standard IDE or with a standard compiler (without preprocessing).
> This is a significant change in the development process.
> The developer needs to understand the concept of join points
> to define what he
> wants to specify here. A general "no" is as simple as a
> general "yes"... but
> what about the grey in between?
> > > Think again. AOP must seamlessly integrate into the
> > > development process,
> > > otherwise, the adoption rate will be too low. Forcing a
> developer in a
> > > different, non-AOP project to learn AOP just to satisfy your
> > > requirements,
> > > forcing him to fall behind on his own requirements,
> > > propagating changes through
> > > the whole company (or even across companies) to meet one
> > > project's requirements
> > > is not a good idea.
> > It's true, but at this stage I do not consider this.
> You should. AOSD is about applicability, too... at least for
> the industrial
> adopters... and if you make our life harder, we _will_ loose
> faith in your
> approaches and we _will_ look for something else. Sadly, that's life.
More information about the discuss