linton@marktwain.rad.sgi.com (Mark Linton) (05/30/91)
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).
grunwald@mumble.colorado.edu (Dirk Grunwald) (05/30/91)
Is there a reason why data members won't be made 'protected'? I do this all the time in my class library, but wonder if I'm missing something that will affect portability, etc. thanks Dirk Grunwald -- Univ. of Colorado at Boulder (grunwald@foobar.colorado.edu) (grunwald@cs.colorado.edu)