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
--
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 geda-user@xxxxxxxxxxxxxx http://www.seul.org/cgi-bin/mailman/listinfo/geda-user