gnucap-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

attributes, possible interface


From: Felix Salfelder
Subject: attributes, possible interface
Date: Mon, 18 Apr 2022 22:02:31 +0200

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]