Re: gEDA-user: Attribute Net (without pin assignment) - for Power and Port Symbols

[John Doty <jpd@xxxxxxxxx>]

On Apr 14, 2011, at 2:14 PM, Krzysztof KoÅciuszkiewicz wrote:

> But I think we're actually getting farther from something that:
>    * is backwards compatible with the name=value attribute definition/syntx
>    * can be simply used to add hierarchy/depth to attribute assignments
> 
> It would be best to keep these two things aligned - syntax used for
> general transformations should be a natural extension of the one used
> for attribute definitions.

As usual, we discuss *features* to exhaustion, never asking the key question:

"What enabling factors are missing from the foundation?"

If someone wants to write a script to directly process or generate files in .sch format, they just do it: there is no need to negotiate "features" here. They can distribute it, get feedback and enlist help for improvement without disturbing the gEDA core.

Similarly, if someone wants to write a printed circuit netlister or a partlister, they can write a gnetlist back end. No negotiation is required.

This is a consequence of clean, orthogonal, factored design. The .sch format is simple and easy to parse. In particular attributes are easy to isolate and process with simple tools. Fans of XML-based formats should take note. The gnetlist back end API is well adapted to generating partslists and printed circuit netlists. With some extra work, it's also OK for making simulation input. Within those limits, it's well factored and flexible.

We have a more general scripting capability for gschem and gnetlist, but it's crippled by the fact that libgeda and the other hard coded parts interpret attributes, something that they simply should not do. While gEDA is unusually well factored, this is a key place where it needs to be better. Interpreting attributes should be entirely the responsibility of the scripting layer (with suitable defaults provided, of course). While we should strive for uniform, consistent *meaning* of attributes, how that meaning yields concrete results is necessarily application dependent. A classic and troublesome example is slotting, where slots represent independent model instances in simulation, but only a single package in layout.

Fancy attribute translations are exactly the kind of thing that belongs in optional scripts, and not in core code. The core should be simple and clean.

I've heard it said that good factoring is merely a convenience for the developers, a help for maintenance. I strongly disagree. Good factoring is precisely what users need to be able to customize the suite to *their* needs, rather than being mere consumers, hostage to the necessarily limited imaginations and priorities of the developers. A big part of what makes gEDA special is all of the user contributions.

---
John Doty              Noqsi Aerospace, Ltd.

This message contains technical discussion involving difficult issues. No personal disrespect or malice is intended. If you perceive such, your perception is simply wrong. I'm a busy person, and in my business "go along to get along" causes mission failures and sometimes kills people, so I tend to be a bit blunt.



_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user