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=cbqsKzddhciUxb4hDwWnfFVtUoknMVTJsPzxl2wY5f0=;
        b=LOq72uZS5KVg6T0CfY5L5NinRDTmi/Uoyzt0IZNlqTHW7X5X5LzMAnukC8foEZiMup
         +0OPfsZ25/o/uiC7bYwCht1SaA3NoOtlxNMTzFkcz/TUivwQpZJBd9hpl7YWDP0TZutY
         abX0LZGB3xGHAbqa9UDWOWuZ5RwPA/LRzuD+ZjqOjTBo3sXC5X/g+J6IEGSFHXFt3umw
         FnEwTr8wLW/hqUflWxF0vgBNCBnhC0cJV2+vwQWGR8RAJXVMmC19iLtnCbQGBiHvHK0y
         fWe3+QCr8ZrY+kfyTYEA4pVKG70bOr1xajEx+lYSGhQbd5Fujdgye6J3j+NZPKdnR6+U
         EJsw==
MIME-Version: 1.0
X-Received: by 10.50.21.10 with SMTP id r10mr2925058ige.94.1441117419565; Tue,
 01 Sep 2015 07:23:39 -0700 (PDT)
In-Reply-To: <20150901095807.17257.qmail@stuge.se>
References: <20150826000523 DOT 353 DOT qmail AT stuge DOT se>
	<CAM2RGhQi83=d+H6be6z6v7HkchdXqkfkiypKsQf0mM+QGdiH9A AT mail DOT gmail DOT com>
	<55DDD4DB DOT 2060008 AT ecosensory DOT com>
	<20150826153031 DOT 4620 DOT qmail AT stuge DOT se>
	<201508261807 DOT t7QI7sS3003191 AT envy DOT delorie DOT com>
	<20150826182552 DOT 22702 DOT qmail AT stuge DOT se>
	<CAGYR9vci4fCsw05ryrV=NDNbyb6Ng1E3hyD3rF4TeBcdAaqhbg AT mail DOT gmail DOT com>
	<20150831140133 DOT 2dc0456c28430ebcfb0b17b5 AT gmail DOT com>
	<55E4471F DOT 3010906 AT jump-ing DOT de>
	<ms2s9b$rs6$2 AT ger DOT gmane DOT org>
	<20150901095807 DOT 17257 DOT qmail AT stuge DOT se>
Date: Tue, 1 Sep 2015 10:23:39 -0400
Message-ID: <CA+uY=MR7RO_3J6uRB34WTi5dbTB9fBAk2WebkJofZdA45VgcLw@mail.gmail.com>
Subject: Re: [geda-user] SQL PCB file format
From: "Russell Nelson (russnelson 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=047d7b86eeaedf78d6051eb04b39
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

--047d7b86eeaedf78d6051eb04b39
Content-Type: text/plain; charset=UTF-8

Indeed. PCB need not use the same interchange file format as it uses for
its native storage. But I'm not quite seeing the difficulty with the
existing file format. It's plain text, so easy to edit. It's well-known,
with a bunch of tools that manipulate it. I would say to stick with it as
both interchange and native storage.

On Tue, Sep 1, 2015 at 5:58 AM, Peter Stuge (peter AT stuge DOT se) [via
geda-user AT delorie DOT com] <geda-user AT delorie DOT com> wrote:

> Kai-Martin Knaak wrote:
> > >> read through source code and find all functions or similar
> > >> accessing the PCB file and put them in libpcb library file which
> > >> would be become a storage library.
> > >
> > > Pretty much all code accesses the stored data directly, no such
> > > thing like accessors or setters/getters.
> >
> > Something whispers "refactor!" in my ear...
>
> Setters/getters are perhaps the worst side effect there is in source
> code. Never introduce artificial overhead without very careful
> consideration.
>
> Data structures in memory are intended to be accessed directly and
> ideally never copied.
>
> Permanent storage is another matter. Setters/getters for files are
> all the more appropriate - and that's exactly what libpcb and edacore
> both would offer. I'm all for moving pcb file code into a libpcb.
>
>
> //Peter
>

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

<div dir=3D"ltr">Indeed. PCB need not use the same interchange file format =
as it uses for its native storage. But I&#39;m not quite seeing the difficu=
lty with the existing file format. It&#39;s plain text, so easy to edit. It=
&#39;s well-known, with a bunch of tools that manipulate it. I would say to=
 stick with it as both interchange and native storage.</div><div class=3D"g=
mail_extra"><br><div class=3D"gmail_quote">On Tue, Sep 1, 2015 at 5:58 AM, =
Peter Stuge (<a href=3D"mailto:peter AT stuge DOT se">peter AT stuge DOT se</a>) [via <a =
href=3D"mailto:geda-user AT delorie DOT com">geda-user AT delorie DOT com</a>] <span dir=
=3D"ltr">&lt;<a href=3D"mailto:geda-user AT delorie DOT com" target=3D"_blank">ged=
a-user AT delorie DOT com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">=
Kai-Martin Knaak wrote:<br>
&gt; &gt;&gt; read through source code and find all functions or similar<br=
>
&gt; &gt;&gt; accessing the PCB file and put them in libpcb library file wh=
ich<br>
&gt; &gt;&gt; would be become a storage library.<br>
&gt; &gt;<br>
&gt; &gt; Pretty much all code accesses the stored data directly, no such<b=
r>
&gt; &gt; thing like accessors or setters/getters.<br>
&gt;<br>
&gt; Something whispers &quot;refactor!&quot; in my ear...<br>
<br>
Setters/getters are perhaps the worst side effect there is in source<br>
code. Never introduce artificial overhead without very careful<br>
consideration.<br>
<br>
Data structures in memory are intended to be accessed directly and<br>
ideally never copied.<br>
<br>
Permanent storage is another matter. Setters/getters for files are<br>
all the more appropriate - and that&#39;s exactly what libpcb and edacore<b=
r>
both would offer. I&#39;m all for moving pcb file code into a libpcb.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
<br>
//Peter<br>
</font></span></blockquote></div><br></div>

--047d7b86eeaedf78d6051eb04b39--