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: Message-ID: References: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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 Precedence: bulk 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).