Am 25.08.2016 um 09:25 schrieb Jiří Techet:
This is specifically the type of function I want to avoid. This is not extensible at all, so not a good fit for a plugin API. Also, parameter-heavy functions are generally hard to use correctly (it's sometimes necessary but in this case my proposal gives a better solution IMO).But yours isn't very consistent in this respect either - sorting parameters are provided as arguments of tm_query_exec() while the rest is provided by the query setters.
It's a bit like with DB queries. Query filters (WHERE clause) apply to the query itself, post-processing (ORDER BY, GROUP BY) applies to the result set.
Or did you mean to suggest that sorting/dedup should be set with a separate function? Well, I designed it such that these two don't affect the result itself, so that a query can re-run with different sorting/dedup. I guess you could also make _exec() parameter-less and export tm_tags_sort() and tm_tags_dedup() separately but this seems less convinient and makes tm_query interface look incomplete (because the two are in the tm_tags* namespace). But I guess I could live with it if necessary.
If you want to keep the setters instead of function parameters it's fine
- this wasn't the important thing in my comment. But I think it would be
much more flexible if it could be applied to an arbitrary tag array instead of the hard-coded global or session tags. There's for instance no way to get tags for the current document only. I would prefer
|GPtrArray *tm_query_filter(GPtrArray *tag_array, TMQuery *q, TMTagAttrType *sort_attr, TMTagAttrType *dedup_attr) |
and it would filter the source tag_array whatever it is. In fact, I would even prefer splitting this one into two:
|GPtrArray *tm_query_filter(GPtrArray *tag_array, TMQuery *q) |
and
|GPtrArray *tm_sort(GPtrArray *tag_array, TMTagAttrType *sort_attr, TMTagAttrType *dedup_attr) |
For my GI use case I must avoid referencing the `workspace->global_tags` and `workspace->tags_array`, because that's what's slowing down the python plugin (it seems to do stuff with getattr() for each element even if no python code actually accesses the elements). This is the main reason for the abstraction via `TM_QUERY_SOURCE_*`
However, I am open to allow the query API to work also on local tag arrays. I could imagine a second constructor like this: |TMQuery *tm_query_new_from_tags(const TMWorkspace *workspace, TMTag **tags);|
Then the remaining TMQuery interface could also be used on that kind of instance. The `workspace` parameter truly really needed but might become handy later on. `tags` would have to be suitably sorted by tag name though.
For your idea to get tags for a specific document, I'd suggest a new filter. |gint tm_query_add_source_file(TMQuery *q, TMSourceFile *source_file);|
Here shows the strength of the TMQuery interface. Constructors and filters can be added painlessly, without breaking existing users.