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.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.