Tony Marston wrote on 01/03/2016 09:32:
"Rowan Collins" wrote in message news:56d42cd3.6020...@gmail.com...
Tony Marston wrote on 29/02/2016 09:55:
"James Titcumb" wrote in message
news:CAKnqCEY7art1GUWG=pm0wypgqmyp0dq8oxdohgbksgq+o_b...@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]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
