[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [p2-dev] Review wanted. Simplifying the IQueryResult/IQuery API

Thinking more about this.

What I want to avoid is that the developer gets the wrong impression when he looks at the IQueryResult. If it has a size() method, it's somewhat implicit that it is lightweight. I've seen one size() too many in the test of a loop construct for instance :-)

What I think is really needed, is what you mention, the ability to create a collection in a way that, if possible, avoids reallocation as the collection grows. So how about this?

Instead of the toCollection() method (the name says very little on what's going on), we add these two methods:

/**
 * Creates a new List copy with the contents of this IQueryResult. The
 * copy can be altered without any side effects on the IQueryResult.
 */
List copyAsList();

/**
 * Creates a new Set copy with the contents of this IQueryResult. The
 * copy can be altered without any side effects on the IQueryResult.
 */
Set copyAsSet();

This would make the user understand that what he gets is indeed a copy. And since it's either a Set or a List, he can also use that copy directly for various purposes. That would remove the need for a size() method.

What do you think about that?

- thomas




On 2009-12-17 18:30, Thomas Hallgren wrote:
On 2009-12-17 18:26, Pascal Rapicault wrote:

I have not reviewed the patch but I'm not a big fan of the removal of size and toCollection.
They end up being particularly useful in some places, especially to convert from one type to the other, or eventually create collections with the right size up front (which saves a lot of growth when you work on very large collections).


I agree that there are cases where all the IUs can't be held in memory, however there are cases in today's code (engine and planner) where I don't see how not having all the IUs in memory is possible, and where the presence of such methods is necessary.
In the end I think I could probably leave without the toCollection, but loosing size would likely cause performance issues.


I doubt that. I think it's rather the opposite given the number of unnecessary collection copies that were removed.

Is there any way we can compare performance, with and without my patch? Any particular scenarios that you are worried about?

- thomas

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