Mail Archives: geda-user/2016/01/09/07:55:24
| 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=googlemail.com; s=20120113;
|
| h=mime-version:date:message-id:subject:from:to:content-type;
|
| bh=htp7R4prol1on7eP1iZMa6sEyVdTyMM381SDvvHq+Nk=;
|
| b=Vy46dEP8ZGs1typ0YZOPCtKIxTTlWfEBjlxTnE9jI7blLE+IAgwkyMIv6r4SziJ/CG
|
| 4fFOe+7PMnYtOAD4Hne3FlWZCDUbBNfrLphzR2XdH/Ixzcbf0OLP8rxnGwf3kYiahbZ7
|
| APOHvsxDvuqbtHi74nvG44df9Ebb3TuUZRra9XEP3eiMvOvScCA1i0oaVH+clDic+bXv
|
| 4lRqS7GufYRELL0FHGb/GATqQteld3dmI/agdsDUX+L7E5Umq6SRXJp9CkVLoalmyA7p
|
| omS1FBUt9X3Ar+djEEeYBDwxUM9sTvFmdwoWFIXgkS21raVDHGFLn1bXhVHTuh4EsETw
|
| QxSg==
|
| MIME-Version: | 1.0
|
| X-Received: | by 10.182.171.105 with SMTP id at9mr90596235obc.49.1452344110440;
|
| Sat, 09 Jan 2016 04:55:10 -0800 (PST)
|
| Date: | Sat, 9 Jan 2016 12:55:10 +0000
|
| Message-ID: | <CAJXU7q8edycnyhZbZ7+M3q6HA13U4Tr5R9M7KAG59HVpH2+cMg@mail.gmail.com>
|
| Subject: | [geda-user] Primitive electrical types [WAS: Re: first attempt at bus support in
|
| gnetlist for pcb]
|
| From: | "Peter Clifton (petercjclifton AT googlemail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
|
| To: | gEDA User Mailing List <geda-user AT delorie DOT com>
|
| Reply-To: | geda-user AT delorie DOT com
|
--e89a8ff1cfa0cb65c40528e636ea
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On 9 January 2016 at 02:53, Britton Kerin (britton DOT kerin AT gmail DOT com) [via
geda-user AT delorie DOT com] <geda-user AT delorie DOT com> wrote:
>
> On Fri, Jan 8, 2016 at 3:38 AM, John Doty <jpd AT noqsi DOT com> wrote:
>
>>
>> Yes. And then, erase the distinction between nets, busses, pins, and
>> lines. Move that into attributes: a line with netname=3D is a net, a lin=
e
>> with pinnumber=3D is a pin =E2=80=A6
>>
>
> Using attributes like this is effectively a form of duck typing, which is
> fine in principle but often leads to a lot of confusion since the type
> hierarchy is implicit and doesn't end up getting written down anywhere.
> I'm not saying its always bad and gschem already has this philosophy
> anyway, but it does tend to make the whole setup challenging for newcomer=
s
> as they struggle to figure out which sets of attributes they need.
>
> I don't have a concrete idea what could be done about it. It's been an
> issue for every attribute-based system I've worked on and I've never
> encountered a great solution.
>
I'm not sure I'd go as far as to say "gschem already has this philosophy
anyway", since geda does actually treat all these objects as distinct
types, and their types apply semantic meaning when extracting connectivity.
Did you mean "attributes are used in a similar way already"?
Whether or not this is fully factored in the code or not, from the
graphical entity point of view these are effectively sub-type
specialisations of the line primitive, as John has suggested. Whilst it
would be technically possible to take this as a more "duck typed" approach,
I'd probably not suggest it.
Pins and nets have different semantics regarding connection points - for
one example. (One end only, vs. either end - plus end-point to
lands-on-line connections.) To me, this implies there should be different
types internally, even if they are notionally sub-classes.
What one might consider, would be an entity type multiple inheritance, or
composition - between the graphical representation (usually a line), and
other entity types that specialise it (net, bus, pin). I'd like to see a
zero-length connection primitive (pin), that did not have a "line"
underlying it, but that is me being a purist.
Peter
--e89a8ff1cfa0cb65c40528e636ea
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><div class=3D"gmail_quote">=
On 9 January 2016 at 02:53, Britton Kerin (<a href=3D"mailto:britton.kerin@=
gmail.com" target=3D"_blank">britton DOT kerin AT gmail DOT com</a>) [via <a href=3D"m=
ailto:geda-user AT delorie DOT com" target=3D"_blank">geda-user AT delorie DOT com</a>] <=
span dir=3D"ltr"><<a href=3D"mailto:geda-user AT delorie DOT com" target=3D"_bl=
ank">geda-user AT delorie DOT com</a>></span> wrote:<br><blockquote class=3D"gm=
ail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,=
204,204);padding-left:1ex"><div dir=3D"ltr"><br><div class=3D"gmail_extra">=
<div class=3D"gmail_quote"><span>On Fri, Jan 8, 2016 at 3:38 AM, John Doty =
<span dir=3D"ltr"><<a href=3D"mailto:jpd AT noqsi DOT com" target=3D"_blank">jp=
d AT noqsi DOT com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddin=
g-left:1ex"><div style=3D"word-wrap:break-word"><br><div>Yes. And then, era=
se the distinction between nets, busses, pins, and lines. Move that into at=
tributes: a line with netname=3D is a net, a line with pinnumber=3D is a pi=
n =E2=80=A6</div></div></blockquote><div><br></div></span><div>Using attrib=
utes like this is effectively a form of duck typing, which is fine in princ=
iple but often leads to a lot of confusion since the type hierarchy is impl=
icit and doesn't end up getting written down anywhere.=C2=A0 I'm no=
t saying its always bad and gschem already has this philosophy anyway, but =
it does tend to make the whole setup challenging for newcomers as they stru=
ggle to figure out which sets of attributes they need.</div><div><br></div>=
<div>I don't have a concrete idea what could be done about it.=C2=A0 It=
's been an issue for every attribute-based system I've worked on an=
d I've never encountered a great solution. =C2=A0</div></div></div></di=
v></blockquote><div><br><br></div><div>I'm not sure I'd go as far a=
s to say "gschem already has this philosophy anyway", since geda =
does actually treat all these objects as distinct types, and their types ap=
ply semantic meaning when extracting connectivity.<br><br></div><div>Did y=
ou mean "attributes are used in a similar way already"?<br></div>=
<div><br>Whether
or not this is fully factored in the code or not, from the graphical=20
entity point of view these are effectively sub-type specialisations of=20
the line primitive, as John has suggested. Whilst it would be technically p=
ossible to take this as a more "duck typed" approach, I'd pro=
bably not suggest it.<br><br></div><div>Pins and nets have different semant=
ics regarding connection points - for one example. (One end only, vs. eithe=
r end - plus end-point to lands-on-line connections.)=C2=A0 To me, this imp=
lies there should be different types internally, even if they are notionall=
y sub-classes.<br></div><div><br></div><div>What one might consider, would =
be an entity type multiple inheritance, or composition - between the graphi=
cal representation (usually a line), and other entity types that specialise=
it (net, bus, pin).=C2=A0 I'd like to see a zero-length connection pri=
mitive (pin), that did not have a "line" underlying it, but that =
is me being a purist.<br><br></div><br></div><div class=3D"gmail_quote">Pet=
er<br></div></div></div>
--e89a8ff1cfa0cb65c40528e636ea--
- Raw text -