Description david.pearce 2005-12-08 17:09:33 EST

Hi,

The problem I have is motivated by the following:

> class Course {}
> class Student {}
>
> abstract aspect A<X,Y> {
> interface FROM<T> {}
> interface TO<T> {}
>
> declare parents: X extends FROM<Y>;
> declare parents: Y extends TO<X>;
>
> private List<T> FROM.Rel;
> private List<T> TO.Rel;
>}
>
> aspect B extends A<Student,Course> {}
> aspect C extends A<Student,Student> {}

In the current version of ajc, this gives the following error:

> [error] Cannot declare parent A$FROM<Student> onto type Student 
> since it already has A$FROM<Course> in its hierarchy
> declare parents: X extends I<Y>;
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

But, if we expand the generic aspect by hand it works fine:

> aspect B {
> interface FROM {}
> interface TO {}
>
> declare parents: Student extends FROM;
> declare parents: Course extends TO;
>
> private List<Student> FROM.Rel;
> private List<Course> TO.Rel;
>}
>
> aspect C {
> interface FROM {}
> interface TO {}
>
> declare parents: Student extends FROM;
> declare parents: Student extends TO;
>
> private List<Student> FROM.Rel;
> private List<Student> TO.Rel;
>}

This is OK because the interfaces FROM and TO are really B.FROM, B.TO and C.FROM and C.TO which don't clash.  

My example is essentially the ParentChildRelationship example from the website.   Currently, we are limited to declaring one ParentChildRelationship per class (rather than potentially many as is done above).  It would be very beneficial to allow many different relationships to be implemented for a given class (e.g. student->student, student->course etc).

Therefore, I believe it makes sense to treat generic aspects more like C++ templates.  That is, we regard the concretization of a generic aspects as though the aspect were "inlined" into the concreting aspect with type parameters substituted as appropriate.  This would give the desired functionality and would also provide a nice and clear way of reasoning about how generic aspects behave.

Thanks,

David J. Pearce