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=Bq3f/WWFry6ogK+yCj8PB+4W7sjrderz4fY2PmQjhqs=;
        b=MBqapeNKaP1C3dF08v6ChmNZGep9ak4CxVoP6saTyx71kr33cTpE03fMNoijiFWoek
         LYV7957kCE1rKA3uRYUMti8fHuXI78HaAJzQZh8aQ/Qj/5UfMAADJnIjA4hDXDGKd+wd
         95j+CrXC08ByjX2Byz8cYJwWO9fO4oQNsbd78f4Rx+zjTg66+nwzcj4M9Je9FfIRgKOT
         /9BM39v3btE10eDc26ywhBGc9FygA5XC+jOCKpcNRJiQPBKH6n4UvHwBh80guZoCF5zV
         JozhFFlGOe9qjLgX0kj/F5bH5692d8iG4OxwoNLNjDEIAJzsyM/oIFbGA9rXoxcTIzpr
         OW8g==
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=Bq3f/WWFry6ogK+yCj8PB+4W7sjrderz4fY2PmQjhqs=;
        b=LFGoFmQeZkqbHRCLW0W2QRxUZp5S+w61O5xouSuZZRSNTfDdLHzwzmY7kpM8V1sSkH
         IR6HO9/CZd0QAquczmEQDGfz7nDwllhcx0HLDHwoiw6i0IFIPTfncLPN/xFvNJSWDIq2
         8049h72o7Jsy1gFBQY9MAvnAOwU9tpiASZxxxgzFUB9s2XeudsM02e62BgN2MQdZ4l2F
         NUAuM+2oES6322UI32KoCcO62xM2e/nYubimbGIweS/CX+dQHkmnQ5oMDwLjaoX/exrF
         MtcyGpsmWmABqMGNl/WAaEARar3g6/r7MMU/2ZuzrSAXuFy0bBB6nr9CyK7VPdtgb5dc
         uvLw==
X-Gm-Message-State: AG10YORZIswM9BunXyUzCKMA2F+NE+5peuo+M5fjAWcFNEUTcYynVdqicXpZVA7sd3JXhXFhDYecnVmmuwFZZA==
MIME-Version: 1.0
X-Received: by 10.28.23.73 with SMTP id 70mr30219800wmx.37.1453917371372; Wed,
 27 Jan 2016 09:56:11 -0800 (PST)
In-Reply-To: <s6nwpqvfp2n.fsf@blaulicht.dmz.brux>
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>
	<CAC4O8c9RDJc17XGo-H6DuN5h76RKhQmRNGpcn3DKBKUBP=PuCg AT mail DOT gmail DOT com>
	<s6nwpqvfp2n DOT fsf AT blaulicht DOT dmz DOT brux>
Date: Wed, 27 Jan 2016 08:56:10 -0900
Message-ID: <CAC4O8c_RnsJRtDxJ-7Bqemt=m2m3ackzkrTiFPSCAhobKQveyA@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
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id u0RHuGC7009304
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

On Tue, Jan 26, 2016 at 10:40 PM, Stephan Böttcher <geda AT psjt DOT org> wrote:
>
> "Britton Kerin (britton DOT kerin AT gmail DOT com) [via geda-user AT delorie DOT com]"
> <geda-user AT delorie DOT com> writes:
>
>> On Tue, Jan 26, 2016 at 12:19 PM, John Doty <jpd AT noqsi DOT com> wrote:
>>>
>>> On Jan 26, 2016, at 2:02 PM, Stephan Böttcher <geda AT psjt DOT org> wrote:
>>>
>>>> But the first steps should not be "implement b/b vias" or "allow more
>>>> than one pair of outer layers".  It should be something like "expess
>>>> Elements and Vias as subclasses of generic containers that can include
>>>> anything".
>>>
>>> +1
>>
>> So you guys actually want a more strongly typed system.
>
> No.
>
> The Via is a container with Attribute "Via".  An Element is a container
> with Attibute "Element".  The GUI HID shall present those as special
> types to the user, in component libraries and via stack editors. But in
> the data structures those could well the the same as a hierachical
> sublayout.

Sounds reasonable, although also like a lot of implementation work.

>> That's pretty different from gschem, which uses attributes (duck
>> types) for most things.
>
> I like attributes.
>
>> Regarding making arbitrary containers, I'm not convinced its a good
>> idea.  Entire layouts serve much the same purpose and can easily be
>> copied about.
>
> I'd like to instanciate the same sublayout by reference, so I can edit
> the master and all copies follow.  Problem: How to override atributes
> (refdes) on the copies?

I guess if there are real use cases.  So far what happens for me is I
use the sublayout (scripts take care of refdes changes), thenchange it
slightly to fit in the new board, and after that no way do I want it
to follow any subsequent changes to its parent.

>> Admittedly I'm not convinced the other way either, since I generally
>> prefer types to attributes.  However, there's no denying attributes
>> are easier and can be added incrementally.  Type hierarchies have the
>> further disadvantage of being closed to user extension in C (and
>> effectively so in most other languages as well).
>
> Types require that you know all use cases beforehand.

As a mostly academic point some languages (smalltalk, ruby) provide
type systems that actually encourage client extension, and IMO this is
the best approach, but admittedly not widely available.

> How about implementing types in HID code on top of the attribute driven
> data structures?
>
> Container{
>   Attributes{
>         type="Via",
>         origin=(1003mil,234mil),
>         }
>   Circle{layer="microvias-top", radius=20mil, center=(0,0)},
>   Circle{layer="component", depth=20, radius=40mil, center=(0,0)},
>   Circle{layer="ground", depth=20, radius=40mil, center=(0,0)},
>   Circle{layer="component", depth=-35, radius=50mil, center=(0,0),
>          Attributes{thermal="clerance"},
>   Circle{layer="ground", depth=-35, radius=50mil, center=(0,0),
>          Attributes{polarity="neg",
>                     thermal="clerance"},
>   Line{layer="ground", depth=34, ...
>        Attributes{thermal="diagonal,square"}
>       }
>   }
>
> The thermal tool knows about this type="Via" and is allows to delete/add
> objects with attribute "thermal".

Sounds reasonable.  However, while I'm not a big fan of STEP itself  I
do agree with Peter that it would be smart to look at what they did
for this sort of thing.

Britton