[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

gEDA-user: Conflicting attributes (was: [PATCH 1/2] gnetlist: Add access to all attributes ...)

On Wednesday 05 January 2011 19:04:37 John Doty wrote:
> On Jan 5, 2011, at 11:49 AM, Peter TB Brett wrote:
> > On Wednesday 05 January 2011 18:38:04 John Doty wrote:
> >> They're not especially bad. In that project "make clean; make" generates
> >> 2074 lines of chatter, only about 1/3 of them from gschem and gnetlist.
> >> The worst offender is pdflatex.
> >> 
> >> You can see how a warning could easily be lost.
> > 
> > That doesn't make it okay to deliberately break designs which currently
> > work, even if you don't think they deserve to. ;-)
> Is there any evidence that there are any? In any case, in other areas of
> computing it is considered OK for behavior to change between versions of a
> tool for cases when the input is ambiguous. It's not like changing the
> default attribute promotion policy: that wasn't ambiguous.

No, but there wasn't any evidence that that would actually break users either.

Now, I would *very much* like to see this ambiguosity cleared up, but as part 
of a holistic strategy to make attributes clearer and easier to process in an 
automated and deterministic manner.

1) Decide if we wish to continue to allow multiple values for the same 
attribute in the same context (c.f. 'net=' vs 'refdes=" behaviour in previous 
discussion), and document this.

2) Decide which (if any) attributes should be "reserved" for the 
implementation, i.e. have their semantics strictly prescribed rather than 
being "free-form", and document this.  For example, we may wish to prescribe 
the merging behaviour of 'refdes=', but also add an 'id=' attribute that if 
present on a symbol *must* be unique within design.

3) Determine which (if any) widely-used attributes can no longer work in the 
same way as a result of the previous decisions, fully document the changes, 
and create an automated tool to find problems in existing designs and 
automatically update them.

If we are *not* going to be backwards compatible, we should actually try and 
do some *design* and come up with an approach that's both well-documented and 
reasonably future-proof.


Peter Brett <peter@xxxxxxxxxxxxx>
Remote Sensing Research Group
Surrey Space Centre

Attachment: signature.asc
Description: This is a digitally signed message part.

geda-user mailing list