El sáb, 16-12-2006 a las 10:03 +0100, Patrick Bernaud escribió:
[snip]
> > [...]
> > There are a lot of structures in gaf (OBJECT, ATTRIB,...) having prev
> > and next pointers. IMHO, this doesn't make sense nowadays, although I
> > understand they are there because of historical reasons.
>
> There is also a lot of structures already using a GList. Have a look
> at connection stuff and where it is used (moving actions for
> example). You are going to add one more variable with type GList and
> little or no on what it is a GList of. It is not what I call improving
> readability of code.
I don't understand what you mean.
> > [...]
> > Changing the SELECTION* to a GList* is a first step to convert all those
> > structures. In the future, when more structures are converted into
> > GLists, they could use these GList based functions now only used for
> > selections.
>
> Have you considered a GSList instead? :) The SELECTION type has the
> advantage of simplifying any future (if necessary) changes of base
> type (GList -> GSList for example).
Yes, and I was not sure it was worth to try the GSList. The selection is
like a list of objects. Both SELECTION and OBJECT structures were having
prev and next pointers, so the direct conversion candidate was a GList.
I agree it would be easier to change from a GList to a GSList or
whatever structure you would like to use.
Maybe we are talking about general things, and an example would be
better.
For me, a selection list is like a list of objects. Before, if I want to
calculate the object bounds of a selection, I needed a
get_selection_bounds iterating through the SELECTION list. What I
wouldn't like is to have two functions for the same thing.
Now there are two functions doing the same thing:
get_object_glist_bounds (for GList of objects) and
get_object_list_bounds (for a list of OBJECTs).
A next step would be to remove the get_object_list_bounds and use the
get_object_glist_bounds.
How would you declare that function?
Current:
void get_object_glist_bounds(TOPLEVEL *w_current, GList *head,
int *left, int *top, int *right, int
bottom);
If I understand you correctly, we'll be having the following declaration
(maybe with a different function name, but it doesn't matter for this
example):
void get_object_glist_bounds(TOPLEVEL *w_current, SELECTION *head,
int *left, int *top, int *right, int
bottom);
That's not quite representative, since that function is not going to be
used always with a selection. I would like to calculate the object
bounds of a list of objects which are not selected.
If we make the OBJECT conversion the same way, then we could have
something like:
typedef OBJECT GList; /* This is in the headers */
typedef SELECTION GList; /* This is in the headers */
void get_object_glist_bounds(TOPLEVEL *w_current, SELECTION *head,
int *left, int *top, int *right, int
bottom); /* This is in libgeda/include/prototype.h */
Now in a function in gschem:
{
OBJECT *list;
list = ...;
while (list) {
[...]
get_object_glist_bounds(w_current, list, [...]);
[...]
}
}
The get_object_glist_bounds is declared with a SELECTION pointer as a
parameter. It's not quite obvious I could use it directly with an OBJECT
pointer, unless I go to the headers, and see that both SELECTION and
OBJECT are GLists. This is the situation I'd want to avoid.
> > [...]
> > - if you had a thought of an alternative at that time, we could have
> > talked about how to coordinate the merging before you started to
> > code.
>
> No possible merge. The two conflicts and I would have had to remove
> your changes before (which what will likely happen now).
I meant the merging with Peter's changes.
Regards,
Carlos
_______________________________________________
geda-dev mailing list
[email protected]
http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
