On Mon, 2011-04-11 at 23:54 -0700, Russell Dill wrote: > On Mon, Apr 11, 2011 at 6:45 PM, John Doty <jpd@xxxxxxxxx> wrote: > > > > On Apr 11, 2011, at 4:25 PM, Peter Clifton wrote: > > > >> I would advise a note of caution. In general, I don't like it when tools > >> start special casing things like this.. it just feels wrong. > > > > I've long thought it a minor design flaw that indexed attributes > attach the index to the value rather than the name. So, I would prefer > net:1=Vcc, while preserving backward compatibility, of course. > > > > You totally win! This is a really neat idea.. P pin number ":1" doesn't really matter, it is just a way of referring to a particular pin. If we could reference by other means, that would also be cool. I'm thinking of some kind of "id=..." attribute like CSS / HTML / SVG would use to refer to other elements. As someone who's just ranted against lots of magic special cases.. how would people feel to a primitive "id=..." attribute which is handled by API to look up and element's ID. We could make the code DEFAULT to looking up pinnumber= or pinseq= for pins (if an id=... doesn't exist), so the new syntax could key off id=, not pinnumber= or .... Basically, I want to see an unique name= or id= attribute which could be applied to any object, and is not net specific. Also - just a reminder.. All this special syntax with ":" in them, probably means there will naturally be restrictions on the presence of ":" in netnames and various ids. Is that a reasonable restriction, or should we avoid in-band data like this? We should really define what constitutes a legal character set for certain types of attribute / name, and if necessary - any escaping to be used with other characters. -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me)
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