[aosd-discuss] Non academic ideas on AOSD

[Denis Bilas]

Hi Juri,

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.

Thanks,
Denis Bilas


> -----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.
> 
> 
> <snip>
> > > 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.
> 
> Regards,
> 
>      Juri