X-Authentication-Warning:	delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient:	geda-user AT delorie DOT com
Date:	Wed, 16 Aug 2017 10:03:50 +0200 (CEST)
X-X-Sender:	igor2 AT igor2priv
To:	geda-user AT delorie DOT com
X-Debug:	to=geda-user AT delorie DOT com from="gedau AT igor2 DOT repo DOT hu"
From:	gedau AT igor2 DOT repo DOT hu
Subject:	[geda-user] Re: [dev] FYI: pcb(-rnd) internals: explanation on
	type/ptr1/ptr2/ptr3
In-Reply-To:	<alpine.DEB.2.00.1708160918250.27212@igor2priv>
Message-ID:	<alpine.DEB.2.00.1708161000120.27212@igor2priv>
References:	<alpine DOT DEB DOT 2 DOT 00 DOT 1708160918250 DOT 27212 AT igor2priv>
User-Agent:	Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version:	1.0
Reply-To:	geda-user AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	geda-user AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

Forgot an important point:

> Reason #5: since these assumptions about the tree are hardwired everywhere, 
> it's rather hard to make upgrades to the tree (like the groupping concept 
> subcircuits introduced in pcb-rnd, or just adding yet another object type). 
> It's especially too easy to miss a new possible combination of ptr1/ptr2 in 
> one of those many calls. For a long time this was one of the main reasons I 
> didn't start the data model cleanup in pcb-rnd.

Reason #6: if you have a totally valid pointer to an object you obtained 
by anything else than a top-down search on the tree, you can't call the 
functions, because you have no idea what Ptr1 (the parent) should be. The 
workaround is:

- either to not obtain (save, store, pass) objects without 
always starting with a top-down search first

- or if you ended up with an object like that, just try to repeat a 
top-down search for that specific object only to figure Ptr1

Needless to say, both workarounds are slow (run-time penalty) and make the 
code needlessly complicated and somewhat harder to understand 
(coding-time penalty).

- Raw text -