gEDA-dev: glist-dev without screen coordinate caching

[Patrick Bernaud]

Carlos Nieves Ónega writes:
 > [...]
 > I think we talked about this by IRC.
 > For those not aware about this, I changed every SELECTION* by a GList*
 > in the glist-dev branch.
 > You suggested to use: typedef SELECTION GList; without changing the
 > remaining code.

Right.

 > [...]
 > 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.

 > [...]
 > 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).

 > [...]
 > Taking that into account, FMPOV the 'code readibility issue' or
 > 'maintainability issue on the mid to long term' means to remove any
 > existing SELECTION in the code, and begin to use GList everywhere.

I do prefer having a SELECTION type even if it is only an alias to
GList. Since every one else is OK with that, I surrender.


 > [...]
 >  - you would allow us to think about it and how to address that issue. I
 > think we are a team of developers, and a team is supposed to think and
 > work together. Maybe I'm wrong, and we are alone just working by chance
 > on the same project.

Very true. And as a member of this team I have requested that the
merge be delayed so we could discuss what was wrong and whether
the alternative was good enough or not.

 > [...]
 >  - Peter based his work on the glist-dev branch, so there was a high
 > probability that any deep change to the existing code will break his
 > work.

>From what I understand most (if not all) of its changes are prior to
the discovery or the announce.

 > [...]
 >  - 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).



Patrick