Re: attributes, possible interface

[Felix Salfelder]

On Tue, Apr 19, 2022 at 08:55:20PM -0400, al davis wrote:
> You win .. but we have a few topics mixed here.
> 
> I was looking at the code to see if something is there that can be
> reused.  ...  not really.  PARAM_LIST is numeric.
> 
> So how about a new class ...  ATTRIBUTES, or ATTRIBUTE_LIST.

For private use or exposed at the CKT_BASE interface?
(NB: Parameters are in COMPONENT, this is how I got to
"internal" at first.)

> 1. Internal storage?
> Need to keep overhead down when it is not used.

Overhead is constant, (i.e. zero overhead per CKT_BASE instance) if we
do something between the lines of

// option A: access through CKT_BASE
void CKT_BASE::set_attribute(string n, string v){ 
ATTRIBUTES::_attributes[long_label()].set_attribute(n,v); }
pair<string, string> CKT_BASE::get_attribute(i){ return 
ATTRIBUTES::_attributes[long_label()].get(i); }

or

// option B: exposed
ATTRIBUTE_LIST& CKT_BASE::attributes(){ return 
ATTRIBUTES::_attributes[long_label()]; } .

There is no need for shell environment variables, just a global
attribute map.

class ATTRIBUTES{
public:
        static ATTRIBUTE_LIST _attributes;
};

(Or I don't understand).

> 2. Access 
> I think all we need is set by name and get by name (subscript).
> There is no need for by index.

In addition, we need const_iterator access (and then we don't need
by_index). Dereferencing a const_iterator should yield a pair of
strings. We could either use map<string, string> or vector<pair>
internally. Option B then, with an ATTR_LIST similar to PARAM_LIST?

> Error handling ..  Set will always succeed, possibly replacing.  Get
> returns empty string if it isn't there.

In C we have NULL (not there) and "" (empty string). I think in C++,
"not there" should throw, because std::string instances can't be NULL,
for some other (possibly good) reason.

> back to 1 ..
> If all access is through access functions, it can be changed later.

Both, option A and B support this.

> If storage is a simple string, convert to CS which has scan which can
> easily extract the one you are looking for.  The map is probably
> easiest.  I am not sure about empty overhead.

If a single pointer in CKT_BASE is acceptable, we should store an
ATTRIBUTE_LIST* there (whatever the interface is). If not, we need a
global map and a long_label mapping. There may be pitfalls with
long_label. either way, it could be changed at any time.

cheers
felix