X-Authentication-Warning:	delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient:	geda-user AT delorie DOT com
X-Virus-Status:	Clean
X-Virus-Scanned:	clamav-milter 0.98.4 at av01.lsn.net
Subject:	Re: [geda-user] The nature of gEDA layers
To:	geda-user AT delorie DOT com
References:	<alpine DOT DEB DOT 2 DOT 00 DOT 1601180756390 DOT 9035 AT igor2priv>
	<CANEvwqgs3YFnt7m8mA1DN6X2KdWbyr4zpXCVH321vDo1f7CyxA AT mail DOT gmail DOT com>
	<201601261804 DOT u0QI4KEQ009550 AT envy DOT delorie DOT com>
	<E7D351BF-5BBB-41AC-B996-D5E27079A82C AT noqsi DOT com>
	<CAC4O8c-ZyNnCzCDHXkYYabSD4fG8vf+CKmhMycNJujGMPKzQDQ AT mail DOT gmail DOT com>
	<s6nr3h49hrq DOT fsf AT blaulicht DOT dmz DOT brux>
	<DDB07351-7C94-4B5C-99FA-83750CD4592A AT noqsi DOT com>
	<20160126233332 DOT dec2f06f5c74354a3841989c AT gmail DOT com>
	<s6n1t93h4ub DOT fsf AT blaulicht DOT dmz DOT brux>
	<20160127091746 DOT 1c7a976c2752f913921688ac AT gmail DOT com>
	<s6npowne74w DOT fsf AT blaulicht DOT dmz DOT brux>
	<20160127141334 DOT c738feb9dbeb54a7dec3dff8 AT gmail DOT com>
	<s6n37tjt1tv DOT fsf AT falbala DOT ieap DOT uni-kiel DOT de> <56A8F74B DOT 8080304 AT ecosensory DOT com>
	<CAC4O8c9UKLsh5FAAwUMEtHThKH-w3gUmCU2i9dRW9igkyRt-TQ AT mail DOT gmail DOT com>
	<CAJZxidDmjMtd_fKvR5qZVRa+hwDUbvfaz79oZjkBgDuE1m8RBg AT mail DOT gmail DOT com>
	<56A961BC DOT 3040405 AT ecosensory DOT com>
	<CAJZxidC=nbxAinOtpfGHHqwPXbEMrhfat7jKgA9KBp3EVVg4_Q AT mail DOT gmail DOT com>
	<s6nbn863xlu DOT fsf AT blaulicht DOT dmz DOT brux>
From:	John Griessen <john AT ecosensory DOT com>
Message-ID:	<56A9E416.8080500@ecosensory.com>
Date:	Thu, 28 Jan 2016 03:49:10 -0600
User-Agent:	Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
	Icedove/38.4.0
MIME-Version:	1.0
In-Reply-To:	<s6nbn863xlu.fsf@blaulicht.dmz.brux>
X-MIME-Autoconverted:	from quoted-printable to 8bit by delorie.com id u0S9nFq5031500
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

On 01/28/2016 02:41 AM, Stephan Böttcher wrote:
> "Chad Parker (parker DOT charles AT gmail DOT com) [viageda-user AT delorie DOT com]"  writes:

>> >My experience has always been that hard to read spaghetti code is the
>> >result of dealing with special cases that arise from having data structures
>> >and functions that weren't designed quite right. Making things more generic
>> >reduces the number of special cases and allows for the maximum reuse of
>> >structures and functions.
>> >
>> >As I stated in my opening remark, feel free to take or leave my
>> >suggestions. Obviously I think it would be wise to heed them
> So do I.

OK.  If having generic containers for data about a pc board and an assembly of parts onto it helps coding
be easy let's do that.  Naming and documentation needs help in PCB.  The word layer gets associated with
layers of FR4  that are laminated together just by talking about board design, as in whether a layer is between ground or power 
plane layers for transmission-line purpose and/or shielding purpose...

So, if one generic container of data holds a 2D conductor on insulator pattern, and one holds
solder mask and one holds top-to-bottom-via connectivity they don't all get talked about as layers or it
is confusing.

What is a good name for these containers?  Spec group? Pattern group? Data group?
Layer is not a good name -- that should be reserved for documentation of board design concepts relation to commands and such.

If the wording data group or just group is used, you can add a word in front to concisely say most of what's needed:

For instance the futuristic buried via is likely to be specified as: attach the buried-via property to each via pad of data groups 
to connect.  All in between data groups get a default sized buried-via pad magically placed at the buried via location, but not 
more outward layer data groups.

Top to bottom via is likely to be specified as:   Add a via pad to the via data group where you want a top-to-bottom-via.

The "magically" part above will be difficult if more than one buried via not touching, but in one X,Y location is desired -- maybe 
that will
become:  place buried-via pads on each in between layer data group to connect so there is a pad at every layer data group
in between connected traces layer data groups.

Maybe pad rings in between along a vertical conductive path is not even needed by some fabbers of buried vias.

- Raw text -