delorie.com/archives/browse.cgi   search  
Mail Archives: geda-user/2017/08/14/01:17:33

X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
Date: Mon, 14 Aug 2017 07:17:25 +0200 (CEST)
X-X-Sender: igor2 AT igor2priv
To: geda-user AT delorie DOT com
X-Debug: to=geda-user AT delorie DOT com from="gedau AT igor2 DOT repo DOT hu"
From: gedau AT igor2 DOT repo DOT hu
Subject: [geda-user] [pcb] mainline: redundant attributes: bug or feature?
Message-ID: <alpine.DEB.2.00.1708140646240.27212@igor2priv>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Reply-To: geda-user AT delorie DOT com

Hi PCB developers,

what is the policy of PCB with redundant keys in attribute lists? (Same 
key added multiple times with the same or different values.) Is this a bug 
or a feature? If feature, do you plan to keep it?

I am working on a subcircuits in pcb-rnd and I want to use attributes to 
store certain values. I am asking for clarification on how pcb mainline 
plans to handle an attribute corner case in the future so that I can 
decide wether to maintain compatibility on this corner case or not.

Details (pcb mainline side)
~~~~~~~~~~~~~~~~~~~~~~~~~~~

I found that the low level attribute API permits the same key to enter 
the attribute list multiple times:

  - CreateNewAttribute() does this implicitly

  - AttributePutToList() does this explicitly when enabled via an argument

On the high level AttributePut() doesn't allow this and writing an 
existing key the second time will replace the old value. Most of the code 
uses the high level API so most of the code won't not allow multiple 
instances of the same key.

I am a bit confused about what the plan was here. It seems the UI blocks 
the user from creating redundant keys, but the low level code 
has an explicit feature from it and the .pcb parser also seems to allow it 
by using CreateNewAttribute(). In the same time AttributeGetFromList() 
will return only the first match so other than preserving and 
displaying the redundant entries, the code won't be able to (easily) 
access them.

Why I ask (pcb-rnd side)
~~~~~~~~~~~~~~~~~~~~~~~~

In pcb-rnd I am removing support for redundant keys.

Rationale: I already upgraded the code so thate very object can have 
attributes and I am starting to use attributes from the code, e.g. refdes 
and value of a subcircuit would simply be on the attribute list. The only 
way such programmed access would make sense is if we had our keys unique.

How this could affect compatibility
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

While removing it, I have two possibilities:

1. declare that it is a feature in pcb, and make some workaround (e.g. 
renaming redundant keys, like adding a /1, /2, /3 suffix), then probably 
remove the suffix on save to .pcb for proper round trip; makes sense only 
if mainline devs say it's a feature in pcb

2. declare that it is a bug in pcb and simply keep only one of the 
redundant keys (no coding required); this would slightly break 
compatibility on the very extreme case the user depended on adding 
redundant keys to a PCB, layer or element (these seem to be the only 
objects in pcb supporting attributes); or if mainline says it's a bug, and 
they fix it, we can keep 100% compatibility

At the moment I favor 2., as I think 99% of pcb users don't even know 
attributes exist so they didn't intentionally add redundant keys.

TIA,

Igor2






- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019