[Github-comments] [geany/geany] New tagmanager query module (#1187)

[Thomas Martitz]

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 or view it on GitHub:
https://github.com/geany/geany/pull/1187#issuecomment-242358032
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.geany.org/pipermail/github-comments/attachments/20160825/d2c9ee63/attachment.html>