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