Mail Archives: geda-user/2016/01/27/12:56:35
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
- Raw text -