gEDA-dev: More changes

[Peter Clifton]

On Wed, 2007-08-15 at 07:00 -0400, Stuart Brorson wrote:
> > There are cleanups for translating objects, and now (not fully tested),
> > code which uses GLists of OBJECTs for attribute placement and
> > paste-buffers. This saves a lot of code.
> 
> Just a quick question:  Gattrib often dereferences pointers into lists
> instead of using methods to grab attributes.  Bad programming
> practice, I know.....   but it got me to a working program rilly fast.
> 
> Did you run any tests using gattrib to verify it isn't broken now?

Not extensively, but I believe those changes are ok. The lists in
question are basically gschem-only usage, and are used when actively
laying down, or copying components.


There is some stuff I attempted later which starts to remove all
OBJECT->{next,prev} usage, and that will require converting anything
that should operate on a list of OBJECTs to take a GList parameter.

Anyway... it took me all evening to get libgeda to compile again after
starting that little game, and there are still ~200 compile errors /
warnings in gschem!. I've not go the free time to continue with it right
now.

What I'm not sure about, (but I think I'm leaning towards on particular
solution), is how to fixup o_...._add().

These currently assume they are linking the new object into a list.
Suitable replacements:

1. You pass them a GList **, an they can make the link (updating the
list pointer for you).
  - Less flexible if you _didn't_ want to add to a list
  - You have to be VERY careful iterating over lists as they are updated
  + Neat API in the most common case, mostly matching the existing code

2. you pass them a GList * (or NULL), which they append to, and you
update the list pointer yourself.
  - More verbose
  - Always returns a GList, even if you wanted the one item
  + Matches GList API

3. Rename o_..._add() to o_..._new() and have them return an OBJECT*
  - Most verbose for the caller?
  - Do any of the COMPLEX objects want to return multiple OBJECTS for
attributes etc..? In that case, those become "special" cases, returning
a GList of OBJECTS.
  + Allows maximum flexibility in what we do with our new OBJECT
  + Allows future usage to change - say for example if we wanted to
replace GList object storage with some spatial data-structure such as
R-Trees.

#1 & #3 fit GedaList best, should we want to go down that road in the
future. I personally lean towards #1.

Regards,

-- 
Peter Clifton

Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA

Tel: +44 (0)7729 980173 - (No signal in the lab!)