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=2E6iJmVk9MvUjXWohjI+3Fh3xu5LGvMFH8ZxK5TGZJE=;
	b=0pRT5H2jHxidsPwSnAgMgYcziuGH82m2Wp3osamfclhv/gTAifmJU5IbGsQXGcaw8h
	QsYExQhgHyvLiKQRn4050dbl7qzBGdDTrA3DwMpUlFxaolMGKaUcBwJIU/aFZk4yjpxP
	yKOV3SRLvrAz1Zyjc1kU17EwjLzuBxgCVgdXy3OdSrc4kVx+cVDvZltYBZ2rdc87S119
	61JCFNnsbcNeSGIby1XFZITV8tEwiHSUh2Tqq9Y28JeDapVDAnmM2bSwUV9Ga1IeMtr1
	54j0Cl56uZJowgj+5dx57oLc7Pyq7r5Xkp4XWOQNr18PG68GsQuXK7oOSZuQ2Ty6qljf
	2KgQ==
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=2E6iJmVk9MvUjXWohjI+3Fh3xu5LGvMFH8ZxK5TGZJE=;
	b=lT9/pz8NUaXgJPTf20wMH8PzP1VvrwwVf9RFmr+CFMgAmcjhogdHCk1fFLgmdpMPBM
	CkNOpwtrZ0JtWNGJ3q8V1XQK+P9+imdnkycilP7hpaK/OayQOgwRi6NPrhC9WiXQxiPP
	YaR43SDdRByEqxmpG6pw2+ZPcuGDxu0JQFVUbluSYjNCxMJ3HQtI42DjFpxmArQrGM4L
	BX+Eqek3A4ejuJuVvIukDG9Ml4yEYvJbsVozcElwNDhS9UR05MZusRR6Nr/lM5EIWh4m
	jc3HhhBWDa5Q5N2NMOYFyeAAJ3ywYbTBfldg2LYXJybqjkOpqap/4ENz35tEN8KpnibQ
	f1+w==
X-Gm-Message-State:	AG10YOTwg541ztKlJUPVzjYMpbc6GvQeumZTz+Q4CJp2CkvlX1jkI+GEvAfuuu0nmrumeFuZNM1b9KA5f7K9Ug==
MIME-Version:	1.0
X-Received:	by 10.28.23.73 with SMTP id 70mr30295286wmx.37.1453918378463; Wed,
	27 Jan 2016 10:12:58 -0800 (PST)
In-Reply-To:	<56A8F3BE.5080505@ecosensory.com>
References:	<alpine DOT DEB DOT 2 DOT 00 DOT 1601180756390 DOT 9035 AT igor2priv>
	<alpine DOT DEB DOT 2 DOT 00 DOT 1601260416150 DOT 9035 AT igor2priv>
	<56A751EC DOT 8030402 AT iae DOT nl>
	<20160126124701 DOT 0d061912c7e078ced9d4e6cb AT gmail DOT com>
	<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>
	<56A8F3BE DOT 5080505 AT ecosensory DOT com>
Date:	Wed, 27 Jan 2016 09:12:58 -0900
Message-ID:	<CAC4O8c81ZDSFyVk6aygf1eY0Vw3DPWO1-kzUpTF9ohXK=cpRYw@mail.gmail.com>
Subject:	Re: [geda-user] The nature of gEDA users
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 u0RID2mt010729
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 Wed, Jan 27, 2016 at 7:43 AM, John Griessen <john AT ecosensory DOT com> wrote:
> On 01/26/2016 03:02 PM, Stephan Böttcher wrote:
>>
>>   It should be something like "expess
>> Elements and Vias as subclasses of generic containers that can include
>> anything".  It should be steps that allow to do anything that may come
>> up in the future that can be expressed in (Gerber) layers.
>
>
> Yes.
>
> On 01/26/2016 04:35 PM, Britton Kerin (britton DOT kerin AT gmail DOT com) [via
> geda-user AT delorie DOT com] wrote:
>> So you guys actually want a more strongly typed system.
>
>
> Isn't PCB already strongly typed and we'd lie a couple extra types?  Isn't
> outline, that chops
> the extents of a layer, a type?  Not sure of the terminology type.

PCB has about the minimum number of types it can have and very little
hierarchy.  With blind vias, you could either make an independent
BBViaType or something, or add a container type like people are
talking about.  BBViaType could in theory be a parent of ViaType, but
there is no ViaType, PinType is recycled for use as vias, so in
practice you'd just make it totally independent.  This approach would
be consistent with how pcb generally does things.  Adding a container
type is better in theory, but somewhat inconsistent with the pcb
approach, and its more work and not so easy to anticipate all the use
cases for the parent type.

> Layers can be 2D and valuable, and maybe they should be redefined to mean
> "corresponding to
> physical stack up layers of material that comes in sheets, or is plated or
> printed on a plane.
>
> The vertical via walls of plated metal would not be part of a layer, just
> inferred.
>
> outline would act on layers, but not be one.
>
> Attributes galore can help layers model physical reality, such that someone
> could extract/infer/construct a CSG
> 3D model from it if they wanted to.

Yes, good idea.  If layers need precise physical meaning for some
applications let them get it from attributes or something, rather than
committing to anything too specific.

Britton

- Raw text -