On Fri, Apr 12, 2013 at 6:24 PM, Rémi Arnaud <email@example.com> wrote:
Pooling queries isn't a problem.
It does pool queries just the same, it's just taking control away from a user to individually address and group them in any meaningful datastructure that matters to users.
Not at all. The main difference is that the user cannot ask for a query before they are available. User can only access the 'results' from the parameter passed into the callback.
I don't understand how the proposed API takes control away from the user to individually address a query, it actually provide a way to group queries. User can query any number of timers in the callback and save this in whatever data structure it want.
It's not a burden.
It's not a problem.
Ok, still the proposed API avoid the need to user to do 1000s of allocation, 1000s of garbage collection. I thought this would be of interest in the concept of a real time (1000s times per frame) use.
The current API enables to individually address single queries, that a user holds, in data structures that matter to them, which is not a list.
The proposed API does exactly the same, except that the queries are grouped and available as a (whatever you want to be) array, list…. They are individually addressed in the callback, the user can put the result it whatever data structure it want….
There can be thousands of sets in hundreds of hierarchical levels.
Sure, there can be hundreds of sets. The proposed API enable grouping the queries in sets, provides callback (event) when a given set if available, avoid pooling issue as mentioned in this email thread
Verdict: stop inventing problems that don't exist and make the API even less usable.
Sorry, but I beg to differ. I see the proposed API more usable, faster, solving the reported issues, and working in all the use cases that were described.