Re: [anjuta-devel] Rethinking the AnjutaProjectNode API

[Abderrahim Kitouni <a kitouni gmail com>]

Hello Sébastien,

> > As a user (the Vala support plugin), I just did what I wanted to do when
> > we were discussing the API in the first place, and it seems to work
> > perfectly. I have used anjuta_project_source_get_node_from_file and
> > anjuta_project_node_parent_type which weren't used. I think the former
> > (along with similar functions anjuta_project_group_get_node_from_file
> > and anjuta_project_target_get_node_from_name) should be correctly
> > namespaced as anjuta_project_node_get_{source,group}_from_file and
> > anjuta_project_node_get_target_from_name (or maybe something else).
>
> The issue here is that I could have several node corresponding to the 
> same file. By example if the same source file is used by a several targets.
>
> I don't really know how to handle this case. Returning only one node as 
> it is done currently looses some information. On the other hand, 
> returning a list of nodes is more complex and it wasn't useful in the 
> use cases that I have seen.

I'm not asking for a change in behavior, the correct behavior is fine
with me. Even if the source file is used by multiple targets, I could
work with whatever target I get.

What I was asking for is more cosmetic: changing the name of those
functions so they appear as methods of the node in the bindings.

> Then, another issue is that I want to be able to add new type of nodes 
> and it would be better if I don't need to add new API functions too.

I think you don't need to worry for now, even those functions are unused
now. But still, it may be a good idea to have only one function that
takes the type of the node as argument (I don't know how it could be
named though).

> > Now I'd like to get the VALAFLAGS of a given target, and I can't find a
> > way to do so except to traverse the custom_properties list matching the
> > name field against something like "Vala compiler flags:" which looks
> > more like a user interface string than a machine-friendly one.
>
> In my idea, you have to match it against "Vala compiler flags:". This is 
> already and ID string, it is just more obvious for the translator to get 
> the expected translation. We could add another string like "VALAFLAGS" 
> which is not translated though.

This is the solution I was thinking about. Another idea (that could be
used in addition to this) is to use a hash table instead of a list to
ease lookups, or maybe not: it might be enough to just have a
lookup_property method.

> I have already get this problem inside the autotool plugin and I have 
> solved it by using the additional members of an autotools property. 
> Obviously you cannot use this "solution" outside.

Yeah. If we add a new id string, would your solution still be useful for
something (ans should be kept) or would it become completely useless?

Regards,
Abderrahim