[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[p2-dev] Review wanted. Simplifying the IQueryResult/IQuery API
- From: Thomas Hallgren <thomas@xxxxxxx>
- Date: Thu, 17 Dec 2009 17:30:26 +0100
- Delivered-to: email@example.com
- User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:18.104.22.168pre) Gecko/20091014 Fedora/3.0-2.8.b4.fc11 Lightning/1.0pre Thunderbird/3.0b4
I've done some work to simplify the IQueryResult/IQuery API further.
Once Ian's patch came in yesterday, it was possible for me to move
forward on two things that I wanted to do for some time.
1. Establish a clear separation of concern between query processing and
the processing of a query result.
This item was very easy to do now. The work entailed three things:
- Removal of the addAll() method from the IQueryResult
- Make IQuery.perform() return an IQueryResult instead of a Collector
- Remove the Collector argument from the IQuery.perform()
Now the IQuery looks like something that produces a read-only result.
This is very much in line with how the QL is designed and will make the
integration that I'd like to do as the next step very easy. It will also
vouch for some furhter performance improvements since we can write very
streamlined IQueryResults for different purposes.
2. Avoid use of collections as long as possible.
A query can produce a huge result. Huge results take up a lot of memory.
Consequently, a good 'query' design should not encourage the use of
collections unless they are absolutely necessary. I did the following to
- Removed the 'size()' from IQueryResult
- Removed the 'toCollection()' methods from the IQueryResult
The toCollection() would always create a copy of the Collector
collection. In many cases, this collection was obtained only to pass as
an argument to the constructor of another collection. In some cases, the
collection was only obtain in order to get the size. Now, when neither
method is there, it's less intuitive to use a collection and more
intuitive to use an iterator. This is a good thing since the query
result may be very large. In case of QL, it may not contain a collection
in the first place.
I just submitted a new attachment to
https://bugs.eclipse.org/bugs/show_bug.cgi?id=298023 because the other
one went stale almost immediately. Not surprising since it touches a lot
of files. But it does show that a review is somewhat urgent. So please,
if you could take a look and give me a go ahead, or a reason not to, I'd