Re: [RFC Proposal] var keyword deprecation/removal

Tony Marston wrote on 01/03/2016 09:32:

"Rowan Collins" wrote in message news:56D42CD3.6020602@gmail.com...

Tony Marston wrote on 29/02/2016 09:55:

"James Titcumb" wrote in message news:CAKnqCEY7art1GUWG=Pm0wyPGQmYp0Dq8oxdohgBkSGq+O_BTZw@mail.gmail.com... Incorrect. It *may* be modified, but surely any invalid modifications will be detected in the testing phase?

Detected by whom? Using what tool?

If changing a variable directly instead of using a setter does not produce an error that can be detected in your testing, whether that testing is automated or manual, then is there actually an error? If doing something does not cause a problem there there is no problem that needs fixing. Preventing something from happening which does not cause an error even if it did happen seems like wasted effort to me.

Firstly, no test suite can ever truly cover 100% of scenarios that the live application will encounter, so the idea that a bug doesn't exist until it causes an error is asking for trouble. You want to catch mistakes as early as possible, and that is exactly what member visibility is there for in the first place - to stop you in your tracks if you try to access something that was supposed to be internal. Secondly, violating visibility may have repercussions outside actual errors. Consider something relying on accessing an "internal" property and writing dozens of lines of code assuming it is of a particular type. Then consider that the maintainer of the module which declared it refactors and removes, renames, or changes the type of that property, confident that they are safe to do so because it was for internal use only. The result is much more wasted effort than keeping an eye out that you're not violating visibility in the first place. Regards, -- Rowan Collins [IMSoP]