On Apr 9, 2009, at 6:16 AM, Stefan Salewski wrote: > I wonder why gEDA attribute handling works not in this simple manner: > > - attributes can be defined in symbols > > - gschem takes these attributes from symbols and allows overwriting. > > (For each attribute of the form a=v the position (relative to the > symbol > reference point) and visibility is stored.) > > If a symbol is inserted in a schematic gschem has only to store the > path > to that symbol file and the position in the schematic. > > All attributes are accessible in gschems attribute editor, and the > visible attributes are displayed and printed. > > Now the user can redefine arbitrary attributes -- they overwrite/ > shadow > the attributes from the symbol. And of course the user can define new > additional symbols. >
Shadowing works now, and I use it all the time. However, it's not clear to what extent this was a planned feature, or to what extent we can count on it. There are warring concepts here. There's the light versus heavy symbol debate, which disguises the real issue: the way we think about components in EE reflects a "class hierarchy". Then there are those who want to make schematics "self contained" with embedded symbols, an even more extreme approach than attribute promotion. For me, this would be a disaster, a severe barrier to design revision and reuse (it's analogous to making a copy of a subroutine in every file that calls it, rather than linking to a library). Years ago, I suggested to Ales that we needed an OO approach to symbols. He frowned. But it seems to me that's the essence of what you propose, and what Miles wants, too. Perhaps it only needs to have two layers, not a full hierarchy. But I can readily see myself using a heavy instance overriding some attribute of a heavy project symbol that in turn is based on a light library symbol. In fact, I do this all the time, but I wind up copying the light library symbol rather than referring to it, as a real OO approach would allow. > > Where is the problem by this simple approach? > Cognitive dissonance in the minds of users and developers, whose minds actually work hierarchically, but who expect, based on traditional practices, that component management is flat. > John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com _______________________________________________ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user