Re: gEDA-user: gEDA attributes -- why not in this simple way

[John Doty <jpd@xxxxxxxxx>]

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/
jpd@xxxxxxxxx




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