On Mon, Mar 22, 2010 at 10:57, Peter Schneider <[email protected]>wrote:
> Hi there,
>
> is there any reason why 'generate lint' doesn't like protected members?
> I always get something like this
>
>
> D:\psv3\infoDesk20\frontend\source/class\infodesk\ui\test\WinTable.js
> (52,1):
> Protected data field in 'this._table'. Protected data fields are
> deprecated.
> Better use private fields in combination with getter and setter methods.
>
> Do I have to use private members when I don't use them in derived classes?
> Why?
>
> The only way to get rid of those warnings/infos/errors is changing the
> accessibility from protected to private.
> Is this intended behavior? If yes, why?
>
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.
Derrell
------------------------------------------------------------------------------
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
