Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [aspectj-users] [OT] development style

Thanks Matt for commenting on this. Unfortunately, I don't think I am following you.

Let me reformulate it, so that I can check if I get it correctly:

/**
 * Normal class. Everybody is working with this one.
 */
public class NormalClass {
}

/**
 * An interface describing some new functionality.
 */
public interface SomeAdditionalFunctionality {
}

aspect ApplySomeAdditionalToNormalClass{
	declare parents: NormalClass implements SomeAdditionalFunctionality;

	// implementation of SomeAdditionalFunctionality
}

Your suggestion is saying: if somebody is gonna need the functionality added by SomeAdditionalFunctionality (somebody else than the aspect itself), than change NormalClass to implement the interface and only provide the default implementation through aspect.

Indeed this makes a lot of sense to me, but would make the NormalClass source unworkable in any other IDE than Eclipse, or will be showed with error if not using AJDT editor.

This is the problem I am trying to solve. I would like to ask you if this would make things better:

package foo;

public class NormalClass {}



package bar;

public interface SomeAdditionalFunctionality {}


package foo;

public aspect NormalClassImplementsSomeAdditionalFunctionality {
	// only the declare parents here
}


package bar;

public aspect DefaultSomeAdditionalFunctionalityImplementation {
	// default implementation of SomeAdditionalFunctionality;
}

At least this will allow the developers to work with whatever IDE and editors they like with normal classes, and also may provide enough information to them to understand how the SomeAdditionalFunctionality applies to NormalClass.

Please let me know what do you think?

./alex
--
.w( the_mindstorm )p.




#: Matthew Webster changed the world a bit at a time by saying on  11/30/2005 4:50 PM :#
Alex,

You need to avoid this 3-way problem: target class, aspect, client. Either the fact you have added the interface should be known only to the target class and aspect or be transparent to others. In the situation you describe the concern has "leaked" out and is no longer properly modularized. Others need to know the interface is supported so changing the source to reflect that makes sense. You can still use the aspect to provide default method implementations.

Matthew Webster
AOSD Project
Java Technology Centre, MP146
IBM Hursley Park, Winchester,  SO21 2JN, England
Telephone: +44 196 2816139 (external) 246139 (internal) Email: Matthew Webster/UK/IBM @ IBMGB, matthew_webster@xxxxxxxxxx
http://w3.hursley.ibm.com/~websterm/
Please respond to aspectj-users@xxxxxxxxxxx Sent by: aspectj-users-bounces@xxxxxxxxxxx
To:     userAJ <aspectj-users@xxxxxxxxxxx>
cc: Subject: [aspectj-users] [OT] development style


Hi!

The last few hours I have been spent some time thinking how the development inside a team should work in the following scenario. Here is the short story:

1/ I have a few `core´ aspects that I would like to implement and use
2/ These are mainly meant to add `features´ to the domain model (f.e. make the domain model implement IReferenceable and provide the default implementation. This falls very close to the example in Eclipse AspectJ book with listeners). 3/ The exposed public API can be used in some of the application layers (f.e. inside services).

Now my worries/questions are:
1/ how are the other team members gonna see the `additional´ API
one approach would be to create a packaged jar with the weaved version, and the others to work with it; but this will not work if the development happens on the same sources (same project), but different packages;

2/ the AJ java editor is able to handle quite well the references to ITDs, but unfortunately is not (yet) as good as the Java editor; moreover Java editor is the default one, so they will think the project has errors, even if it is compilable.

[I will not bring into discussion the extreme situation where the team is using different tools :-) ]

3/ I have thought that using the @AJ will solve this and allow the other developers to use the Java default editor, but unfortunately with ITD the problem is the same.

4/ navigation: it is not yet possible to navigate to an ITD (or I just missed it). Considering the following example, the rest of the team may start to be dizzy about what is happening to the project:

[code]
public class Foo {
}

public aspect ReferenceableEntityAspect {
                 declare parent: Foo implements IReferenceable;

                 public void IReferenceable.setReference(Long id) {
                                 [...]
                 }

                 public Long IReferenceable.getReference() {
                                 [...]
                 }
}

public class Bar {
                 public void someMethod(Foo foo) {
Long refId = foo.getReference(); // <= here the Java editor is reporting an error; the AJ editor is unable to navigate
                 }
}
[/code]



Is it something that I am missing? I would really like to find out how other advanced AJ users are handling the development while using AJ.

thanks in advance for any hints and suggestions that will allow me to go this way or the correct way. I have the feeling that it would be a really mistake to dismiss AJ in this project, but I don't want to have bad/mixed feelings inside the team.

./alex
--
.w( the_mindstorm )p.

_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-users






!DSPAM:438dbcbb8231383254889!



------------------------------------------------------------------------

_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-users





!DSPAM:438dbcbb8231383254889!




Back to the top