#54 Can't determine the assosiation inited by another way

[Alexander Ilyin]

After we create the association or encapsulation it is generated in the source as the initialization of the field in the constructor. F.g.

public SomeClass {
private List<SomeItem> someItems;

public SomeClass {
someItems = new List<SomeItem>();
}
}

Then we can change the code to the equivalent one like below:
public SomeClass {
private List<SomeItem> someItems = new List<SomeItem>();

public SomeClass {

}
}

And Green lost this link.

Also it will be nice if Green can recognize the link even if we change the List class on some other container like Set, Hashtable, array, Collection etc or some of the subclasses of the List.

[Carl Alphonce]

Logged In: YES
user_id=862234
Originator: NO

This is an issue with the way we defined the semantics for this relationship. This could be changed by defining a new semantics plug-in for composition, to allow for initialization at the declaration. I don't know that we will do that, but you are welcome to if you'd like. The source for the semantics plug-ins is available: each one defines three visitors on the JDT AST: one to generate the relationship, one to remove it, and one to recognize it.

The issue with supporting different types of collections is one we're intending to address. I am not sure at this point about timeframe, but it has been requested previously.

[Alexander Ilyin]

Logged In: YES
user_id=871710
Originator: YES

Why your semantic take care about how the field is initialized? Is it enough to determine the relationship and it's kind just to look at the field type?
If the field type is some kind of container like List<E> or Collection<E> or SomeType[] etc then it can be recognized as relationship regardless how and where it is initialized.

Another way and possible good enhancement to the first one for complex cases is using the Java5 annotation mechanism in place where field is declared. F.g. to differentiate the type of relation, cardinality etc. Something like:

@GreenAssosiation(cardinality="2..6")
List<SomeData> listOfData;

[Gene Wang]

Logged In: YES
user_id=1520789
Originator: NO

Moving this to Feature Request since the nature of the problem is not an unexpected behavior.

[Anonymous]

Logged In: YES
user_id=1231978
Originator: NO

The relationships should be changed to recognize cardinality for Collection or any subtype of Collection. It'd be nice to have a preference for Green that allowed the user to choose which type of Collection they'd like by default. The default could be NULL, which would prompt the user to select a concrete implementation (we have a dialog for that). You could have a "save as default" button on the dialog, so that people who always wanted to generate ArrayList collections could do so; the same could be done for the declared type (e.g., Set, List, Collection, etc.)

As for the relationship specification, the recognizers need to be made more abstract. A possible solution is to create them as listeners and fire events during AST traversal. This is complicated to explain. This ties in with a Green subproject I was looking at a long time ago, which involved an abstract specification of relationships. We'd have "intelligent" generator/recognizer/remover classes that understood the significance of a single relationship specification (e.g. Assoc=Assignment[field, param]).

The easiest thing to do, as mentioned before, is to simply create your own relationship type. Take a look at the source for the association relationship to see how this could be done. The changes would be rather minor.