> Back in the day, we had a number of significant problems arise when > subclasses, unaware that some deep-up-the-hierarchy superclass was depending > on a protected variable name, would use that same variable name and break > things without any indication of why things got broken. It is therefore > highly advisable to avoid protected variables. Instead, use private > variables and, if necessary for subclasses to get at those variables, add > protected accessor methods. This is still does not completely rid the > original problem, but it solves much of the problem.
Thanks for this information! The 'trick' with "privatizing" the protected members is exactly what I am currently doing. I just wanted to be sure that all these many extra underscore are worth it ;) > > Derrell Peter ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
