cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

Parameterize the wt.fc Collection classes

Parameterize the wt.fc Collection classes

One of my biggest annoyances with the Windchill libraries is that whenever you encounter a WTCollection type in some code, there is no way to know what kind of item will return from it's get and it's getPersistable method.

For example:

foo()

{

     QuerySpec spec=new QuerySpec(PartList.class);

     //...build query here

     WTCollection parts=(WTCollection)PersistenceHelper.manager.find(spec,new WTArrayList());

     Iterator<WTPart> iter=parts.persistableIterator(); //<---COMPILES FINE, BUT WILL THROW RUNTIME EXCEPTION

     while(iter.hasNext())

     {

          //....etc....

     }

}

There is no way to know until you go to run it if the WTCollection "parts" actually contains WTPart objects.

If it doesn't, you'll get a runtime exception.

What I'd like to see is all of the collection type objects in Windchill modified to support type parameterization

example:

foo()

{

     QuerySpec<PartList> spec=new QuerySpec();

     //....build query here....

     WTCollection<WTPart>=(WTCollection<WTPart>)PersistenceHelper.manager.find(spec,new WTArrayList<WTPart>); //<---COMPILER ERROR

     Iterator<WTPart> iter=parts.persistableIterator();

     while(iter.hasNext())

     {

          //....etc....

     }

}

In the case of getPersistableIterator, we expect it to return WTPart or PartList.

In the case of getIterator(), we would expect it to return a parameterized WTReference

example:

Iterator<WTReference<WTPart>> refIter=parts.iterator();

This would remove a MASSIVE headache for me as a developer.

Thanks.

3 Comments
sray
1-Newbie

I agree with Thomas. I'm currently facing difficulty with initializing a WTCollection (more so because it doesn't allow type parameterization) . If I leave it null, I face a NullPointerException. I am unable to add any WTObject to the WTCollection if it is uninitialized.

tlyons
1-Newbie

It seems to me that a good start to the change would be to modify any Windchill library classes that extend a standard library class that supports type parameterization to ALSO support type parameterization.

So if your IDE complains that the class you are extending or the interface you are implementing is not supposed to be a raw type, that class is a good candidate for this change.

Anything that implements java.lang.Iterable, for starters....




olivierlp
Community Manager
Status changed to: Archived

Hello,

We are archiving your idea as part of a general review. This action is based on the age of your idea and the total number of votes received, as per this announcement.

You can always post a new idea with all the details required in the form.

Thank you for your participation.