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: 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]" To: gEDA User Mailing List Content-Type: multipart/alternative; boundary=e89a8ff1cfa0cb65c40528e636ea 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] wrote: > > On Fri, Jan 8, 2016 at 3:38 AM, John Doty 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

= On 9 January 2016 at 02:53, Britton Kerin (britton DOT kerin AT gmail DOT com) [via geda-user AT delorie DOT com] <= span dir=3D"ltr"><geda-user AT delorie DOT com> wrote:

=
On Fri, Jan 8, 2016 at 3:38 AM, John Doty = <jp= d AT noqsi DOT com> wrote:

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

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.

=
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

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.

Did y= ou mean "attributes are used in a similar way already"?

=

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.

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.

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.

Pet= er

--e89a8ff1cfa0cb65c40528e636ea--