woohoo!! Smalltalk! He said Smalltalk! You are my hero for the day.
Seriously, there appear to be several people with serious reservations so I don't see how the type can be removed for 3.6. Can we declare this topic done?
On 2010-03-31, at 2:47 PM, John Arthorne wrote:
I suspect from bug 304130 my opinion on this is already known, but just to be clear I'm still very much against removing MatchQuery. I think _expression_ queries are very useful for a limited set of use cases, and the built in _expression_ queries provided by QueryUtil that exploit repository indexes are great. However, I think an alternative to _expression_ queries needs to exist for clients who want to write custom queries and have nothing to gain from using _expression_ queries and don't want to live with their added complexity. When I originally created the query API I intended it as a very general purpose mechanism much like the Smalltalk select: statement (in hindsight maybe I should have called it that and we wouldn't be having this debate), and I think it would be a mistake to constrain our API to only allow _expression_-based queries.
On Wed, Mar 31, 2010 at 11:19 AM, Thomas Hallgren <thomas@xxxxxxx>
As stated in the deprecation note for MatchQuery, we would like to get rid of this class for M7. We are also very anxious not to disrupt our clients.
Clients may depend on the deprecated class. An alternative solution is included in the deprecation note but some code still need to be moved.
1. Tests show that performance is at least a 100 times better when indexes are used. A MatchQuery can never use an index.
2. We don't risk queries that have side-effects during evaluation.
3. The _expression_ evaluator can be cleaner if concerns about MatchQuery are removed.
4. API is cleaner and easier to elaborate.
5. Queries can be executed by a service in another process (database, remote, etc.)
6. No need to expose API for, or document, internal query behavior.
p2-dev mailing list
p2-dev mailing list