Re: [anjuta-devel] New project interface and introspection

[Sébastien Granjoux <seb sfo free fr>]

Hi Abderrahim,

Le 25/09/2010 23:38, Abderrahim Kitouni a écrit :
> You scared me. I thought all node methods will really have an additional
> argument. But looking below, I only see the load/save/add/remove have
> moved back to the project interface.

Yes, all methods allowing to move in the project tree don't need a 
specific implementation and are working the same whatever is the 
project, so they don't get the project pointer.


> These are here to actually load from/save to the filesystem. They make
> sense here to avoid making assumptions about the actual project format.

Do you mean the project format in the memory (not on disk) ?

Do you want an abstract node object ? I mean a node object without any 
member and only virtual functions including basic one like 
anjuta_project_node_get_file, anjuta_project_node_next_sibling, 
anjuta_project_node_first_child....


If yes, this is really new, I haven't planned to go here. Why do you 
want such design ?

It's more flexible but it means that all project backends will have to 
re implement all the basic stuff. I think it's better to concentrate on 
the project format on the disk and implement a way to translate it to a 
common format in memory. I have though that you were quite happy to see 
that you need to implement only 4 functions in a backend.


> And these methods are just for "bookkeeping", right? I mean that, in
> simple backends, they could have a default implementation that just
> forwards calls to the actual node.

Not really, for me the "bookkeeping" methods are all methods defined in 
anjuta-project.h, not in this mail. These methods don't have a project 
pointer and allow mainly to move in the project tree (next_sibling, 
first_child) and read common data (node name, node type...).

The two add methods are very important, because they are the only way to 
create a new node. Creating a new node is specific to the backend.

The remove method can be implement in a generic way, setting the remove 
flag, it's done like this currently, but I think it could be useful to 
do something special.


> It was one of my unanswered questions :-) I wanted to get rid of them
> from the start.

Fine, one point that I get correctly.


> > - I have added remove_property and remove_node function.
> I prefer it this way, and the backend is then free to do whatever it
> wants with them.

Ok, it's done like this currently.


> about add_before and add_after
> > The return value has the<transfer none>  annotation, the node
> > is owned by the project.
> The problem is that even the project could be something that doesn't
> have "full control" over memory.

Could you give me a example of such case ?

If the backend doesn't have "full control" over the memory, it has to 
copy the data in an AnjutaProjectNode structure. In the worst case, it's 
more work because it has to maintains its internal data and this 
AnjutaProjectNode structure. But, the AnjutaProjectNode structure is 
quite simple and flexible so I think not too difficult.


> The problem is requiring a 'manual' free in whatever form.

I don't see 'manual' free. Do you see some of them ?


> Well, I feel you're missing the point. I don't want a "function to help
> me implement it in Python". I want a clean OO design, that makes it
> easy, or even pleasant to use.

Indeed, I think I have missed your point. I think we can agree that it's 
an OO API but we probably don't have the same understanding of the 
'clean' word.

I think the current interface is cleaner.
- The properties using 2 lists (native and custom) and pointer on the 
data instead of GList alias are much better.
- I think it's better if the nodes don't use GNode because we have more 
control (a moved node is not reallocated by example). It wasn't too much 
work to re-implement the basic functions.
- Grouping insert and new clarifies the node owner.


Could you propose your ideal interface for project backend ?


> (and btw, even if you end up using this,
> by all means avoid adding generic to the function name, that breaks
> conventions).

No problem, I'm trying to find good name but it's not easy.


> Well, I don't like it much. I feel you're slowly going back to your
> original design.

I'm completely agree. It takes me more than 1 week to use GObject 
instead of simple C structure for project node and 1 day to implement 
this new API.


Regards,

Sébastien