🚀 go-pugleaf

In article <1991May28.200149.11510@ge-dab.GE.COM>, vita@gloucester.dab.ge.com (Mark Vita) writes:
|> We have been doing application development using InterViews 2.6 for
|> about a year, generally with very positive results.  However, over
|> that time we have encountered several instances where we wanted to
|> subclass from various classes in the InterViews library, only to find
|> that we were effectively prevented from doing so because of the way
|> the classes in the library were declared.  To wit: member functions
|> that we wished to override were not declared "virtual", and data
|> members that we needed to access were declared "private" (and thus
|> unaccessible to our derived classes).  Our solution was to patch the
|> source code of our copy of the InterViews library to add the "virtual"
|> keyword where needed, and change the appropriate data members to
|> "protected".  However, we'd prefer not to have to do this, since it
|> means that our local copy of InterViews diverges from the "standard"
|> one.

You should send bug reports about such things (mail to interviews-bugs).
We won't make data members protected, but we will add appropriate access functions.
In this case, you should make sure to specify whether you need read access or
write access (or both).