X-Authentication-Warning:	delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient:	geda-user AT delorie DOT com
X-Original-DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:content-type:content-transfer-encoding;
	bh=i/VOlNPIEUzPLjfA8/h9qZp8Jpf026BvUtF3KHxbFDQ=;
	b=ZiB5+rmxjgKMUvfYff3qbWTzvsPq172u/vho8+lH+bI3WxR9KX5hDFn1Patn1EjfdK
	5HDUJkV2Ppqgykt7CdVM1SPWjr51U4XtjESnZrC08hnumqIuqZfUFsy9ARB7ypYgVXJr
	fh6mu8AWYCRJM5Pcbr4w2cW9zWDJMHK5fNG3BSEy01OrxRcpsd7UE4zKMbihKuE/TBZx
	X+d7YxDHS0PJD8iWdqP/lVGSvdVesptc6g4e7/7fU2lHtogdPsBT90j2vg2n8hhWelI/
	5WqIIk3/FYXIymx2+X5W6HXSlVDtqcBJ4HL17OUhnS6LgrA8ydJ4f5lFbvQgUF7VdYVp
	9X5g==
X-Google-DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:content-type:content-transfer-encoding;
	bh=i/VOlNPIEUzPLjfA8/h9qZp8Jpf026BvUtF3KHxbFDQ=;
	b=Wn7C5rJ0sTy2ZBCzI382wjJGWC+lJEepn14rjrQA1uMsHmgpY5pRJHrt30MaZRe3QY
	VZTsoUA4f0Bj8BEnl7BvwyMoIMj2+HTWlAxxh3HaBu+vwaKzlWfw822muBY6Itbh50pi
	QnalQUBR26vsGT6fIpS6D0xjhn0hFRaso9eSqKA74W75z+EKRZpydXewGzsCjVnxykQ5
	w3d0TzIXVKrHfpozfw8HvV20240F+nH2mCCDmONSa7DuiN1DSKoEi1h9GyOm4VBRS4jw
	aWl7/slpMCEOUn9Z1PEVL0ts7gdoUcVnF5LNk5ljmNFwKYQJ2W0+cbeem48GMNhbOeIK
	qTNA==
X-Gm-Message-State:	AG10YOST7mKvmKhrZwh3Tt8L8+v9aKVVOWE5TAV+b6tZmCIgENIiqlXDDhH2yQegBIfc4ToD9+JPmjqUylMRWw==
MIME-Version:	1.0
X-Received:	by 10.28.23.73 with SMTP id 70mr4949832wmx.37.1454014019748; Thu,
	28 Jan 2016 12:46:59 -0800 (PST)
In-Reply-To:	<s6nmvrp31r9.fsf@blaulicht.dmz.brux>
References:	<alpine DOT DEB DOT 2 DOT 00 DOT 1601180756390 DOT 9035 AT igor2priv>
	<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>
	<56A9E416 DOT 8080500 AT ecosensory DOT com>
	<s6nfuxirm0b DOT fsf AT falbala DOT ieap DOT uni-kiel DOT de>
	<CAC4O8c9D-F3p8sAm2UumoE+uoMZM1ufSP=mNEPeHHpn8YrcSyg AT mail DOT gmail DOT com>
	<s6nmvrp31r9 DOT fsf AT blaulicht DOT dmz DOT brux>
Date:	Thu, 28 Jan 2016 11:46:59 -0900
Message-ID:	<CAC4O8c_EjSO7Bgk8Tk=zy2-TjkXXwAtFwgnvguuw3zGor=vh2w@mail.gmail.com>
Subject:	Re: [geda-user] The nature of gEDA layers
From:	"Britton Kerin (britton DOT kerin AT gmail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
To:	geda-user AT delorie DOT com
X-MIME-Autoconverted:	from quoted-printable to 8bit by delorie.com id u0SKl66S028821
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 Thu, Jan 28, 2016 at 11:08 AM, Stephan Böttcher <geda AT psjt DOT org> wrote:
> "Britton Kerin (britton DOT kerin AT gmail DOT com) [via geda-user AT delorie DOT com]"
> <geda-user AT delorie DOT com> writes:
>
>> It's highly unlikely it'll be easier for just BBVias.  I believe
>> there's already an experimental branch that implements them.  Igor is
>> likely to decide to implement them again while we all talk about it.
>> For containers to pay off several other applications for them would
>> need to exist and be important enough to get implemented.  What are
>> they?
>
> My use cases for a mor egeneralized data model:
>
>  - pad stacks, with differnet pad sizes on middle layers

Everyone seems to want these, to be honest I don't understand what
pads on middle layers are for.  Not mounting components for sure.  If
it's just a node what's wrong with a trace or poly?

>  - hierarchical layout

It can be done now...

>  - rigid-flex baords with more than two outer layers

I've never done these.  I guess the flexing connector layer is on top,
but only where it exists so you can still have components on the layer
below?
There's still only one top layer at any given point?

> To avoid more spagetti special casing in the future for all kinds of
> use cases.

I've just been through a lot of DRC and while it's true that e.g.
geometrical tests could be concentrated in Union types or something,
they're still gonna have to go somewhere and it wasn't that bad to
find them as they are.  Adding abstractions that aren't universally
utilized doesn't necessarily make a code any more comprehensible,
because sometimes-utilized abstractions are arguably more confusing
than none at all.  To justify things like containers on
code-cleanliness grounds a big refactor effort is implied.

Britton

- Raw text -