attributes, possible interface

Felix Salfelder via Gnucap-devel <[email protected]> Mon, 18 Apr 2022 22:02:31 +0200
Newsgroups gmane.comp.gnu.gnucap.devel
Message-ID <[email protected]>
On Mon, Apr 04, 2022 at 10:23:04PM -0400, al davis wrote:
> Side note ...  Attribute instance is a way to stash metadata like
> colors, fonts, where is the label, that could be used in rendering a
> schematic.

I got to the point where I could make use of attributes in lang_geda.cc.

Looking at the standard, it seems we want attributes in anything inherited from
CARD. For this, we need a section similar to the parameter section (but
simpler),

  //--------------------------------------------------------------------
public: // attributes
  virtual void set_attrib_by_name(std::string const&, std::string const&);
  virtual int  attrib_count()const                 {return 0;}
  virtual std::string const& attrib_name(int)const  {return "";}
  virtual std::string const& attrib_value(int)const {return "";}
  //--------------------------------------------------------------------

in e_card.h. Perhaps the storage should be left to inherited classes (same as
with parameters), so we could have

/*--------------------------------------------------------------------------*/
void CARD::set_attrib_by_name(std::string const& Name, std::string const&)
{ untested();
  // defer to child classes.
  throw Exception_No_Match(Name);
}
/*--------------------------------------------------------------------------*/

in e_card.cc.

I have pushed this into the attribute branch to get started...

Some ideas, partly exclusive.
- Store attributes in CARD, not in inherited classes. (overhead?, why?)
- Change getters (iterators?), maybe find/lookup? (ugly?)
- Move proposed additions to CKT_BASE straight away.

best wishes
felix