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;
        bh=SIKDfUu1P0Ag4Z6Q5PJm48DJeMlGBE9ssJWg/Bf2ei4=;
        b=NA8fqlfQEeJN3Nb9EYwlvREZjNHwaiECckzUinefLQb0+sX/gAfsUJY3s4pynwS3Md
         RlbSrGduZDB5hxT2MAVCG1eOu3DtPaD+SN4HcBRmDPBRYrsZoq/NZcaHE/RG6FgBAXZW
         3MfZ2bcRXW6Rzztx2f9u4wKlaK6nf85Hjxjaw+tFJGXHxGKokKjN4WT+llQWtiudZowo
         W0Ch8/mK4dglsgzgpOd73ADHGsSw2bl5ACKumfEGRCnuhAh9Pgu0JLegdPLqpbWN+ZdF
         ejfg9w6kHRRrTHVj+uSqILypu1yYicAs72t2WQtVr3Brtd50jlstx8m04RSXnPM9r2rE
         0TLQ==
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;
        bh=SIKDfUu1P0Ag4Z6Q5PJm48DJeMlGBE9ssJWg/Bf2ei4=;
        b=KUEf9XCI2xxocEqU2Ft0D9xQH8Jp83tOwCwwXdGBG6bYbJZjOeqgI6IL+ZPaH6t1kN
         iaL/Zrx3BS5qOcZWOowUI7fvhLZU6nI0TSM0pNBqDLP/se9tK68t2xXGUn5IlNUC7XpU
         fqYj00KURPwdcD/PmhuPS9Vl9XsWiU1XVaj+UOEnrc6OgXiEXfNswi2hFZsTiuMRgrrq
         hKbZXYdZNyv+QxBQrJlVzcyIaCU4pQLEeUd5eCHz/lAaAP/WAyOCozC8ztlqZXbhFHMA
         bGP241XkLEdpykaEb9e15hDJjmolfgVo1rfXHh/sf+BYkAzX6C3uDilSXc0dLjMkm8Co
         kUAg==
X-Gm-Message-State: AG10YOSJdU5YEEPWdiDCTzSh4QLD7eiK7kM4f/GqIB45KbEIFwworrncqRUqEczEL1LAg9TmZxOckWpuMY0ePQ==
MIME-Version: 1.0
X-Received: by 10.50.150.99 with SMTP id uh3mr714548igb.1.1453951469340; Wed,
 27 Jan 2016 19:24:29 -0800 (PST)
In-Reply-To: <56A961BC.3040405@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>
	<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>
Date: Wed, 27 Jan 2016 22:24:29 -0500
Message-ID: <CAJZxidC=nbxAinOtpfGHHqwPXbEMrhfat7jKgA9KBp3EVVg4_Q@mail.gmail.com>
Subject: Re: [geda-user] The nature of gEDA layers
From: "Chad Parker (parker DOT charles AT gmail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
To: geda-user AT delorie DOT com
Content-Type: multipart/alternative; boundary=001a1134cf80d9d3a0052a5c7469
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

--001a1134cf80d9d3a0052a5c7469
Content-Type: text/plain; charset=UTF-8

My opinion is that the issue of attracting new users is somewhat more about
presentation, providing sensible defaults, and easily understandable tools.
What I'm suggesting is more about what's going on under the hood.

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 or I wouldn't
have spoken up, but I freely admit that I'm not familiar with pcb's code
and coding philosophy.

--Chad
On Jan 27, 2016 19:39, "John Griessen" <john AT ecosensory DOT com> wrote:

> On 01/27/2016 12:40 PM, Chad Parker (parker DOT charles AT gmail DOT com) [via
> geda-user AT delorie DOT com] wrote:
>
>> the point is that the concept of a layer is really a more general
>> abstraction and the physicality of them is an interpretation.
>> Keep the concept of a layer simple, and let the concerns of
>> interpretation and realization happen at a higher level such as DRC, a
>> board house, a chip fab, a technician, etc.
>>
>
> I disagree -- it's conceptually simplifying, and easier to explain to new
> people if there is a correspondence to the real world.
> And it's just a definition that is a choice of documentation and style
> policy first, then a coding rule to follow or break later.
>
> The spaghetti code feeling of looking at PCB C files would be helped much
> by a few hard and fast definitions of style and overall meaning...
>

--001a1134cf80d9d3a0052a5c7469
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr">My opinion is that the issue of attracting new users is some=
what more about presentation, providing sensible defaults, and easily under=
standable tools. What I&#39;m suggesting is more about what&#39;s going on =
under the hood.</p>
<p dir=3D"ltr">My experience has always been that hard to read spaghetti co=
de is the result of dealing with special cases that arise from having data =
structures and functions that weren&#39;t designed quite right. Making thin=
gs more generic reduces the number of special cases and allows for the maxi=
mum reuse of structures and functions.</p>
<p dir=3D"ltr">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 or I would=
n&#39;t have spoken up, but I freely admit that I&#39;m not familiar with p=
cb&#39;s code and coding philosophy. </p>
<p dir=3D"ltr">--Chad</p>
<div class=3D"gmail_quote">On Jan 27, 2016 19:39, &quot;John Griessen&quot;=
 &lt;<a href=3D"mailto:john AT ecosensory DOT com">john AT ecosensory DOT com</a>&gt; wro=
te:<br type=3D"attribution"><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 01/27/2016 12=
:40 PM, Chad Parker (<a href=3D"mailto:parker DOT charles AT gmail DOT com" target=3D"=
_blank">parker DOT charles AT gmail DOT com</a>) [via <a href=3D"mailto:geda-user AT delo=
rie.com" target=3D"_blank">geda-user AT delorie DOT com</a>] wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
the point is that the concept of a layer is really a more general abstracti=
on and the physicality of them is an interpretation.<br>
Keep the concept of a layer simple, and let the concerns of interpretation =
and realization happen at a higher level such as DRC, a<br>
board house, a chip fab, a technician, etc.<br>
</blockquote>
<br>
I disagree -- it&#39;s conceptually simplifying, and easier to explain to n=
ew people if there is a correspondence to the real world.<br>
And it&#39;s just a definition that is a choice of documentation and style =
policy first, then a coding rule to follow or break later.<br>
<br>
The spaghetti code feeling of looking at PCB C files would be helped much b=
y a few hard and fast definitions of style and overall meaning...<br>
</blockquote></div>

--001a1134cf80d9d3a0052a5c7469--