Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91466
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.43 as permitted sender)
To: internals@lists.php.net
References: <1F.91.55238.41F10D65@pb1.pair.com>
 <CAHvhOfhYpnjkSjuo09TY7irhgW5UxNYZcWqtAr0iCcUAqJUgqw@mail.gmail.com>
 <CAKnqCEY7art1GUWG=Pm0wyPGQmYp0Dq8oxdohgBkSGq+O_BTZw@mail.gmail.com>
 <FA.10.10408.29514D65@pb1.pair.com> <56D42CD3.6020602@gmail.com>
 <DB.E1.07778.3D165D65@pb1.pair.com>
Message-ID: <56D57DF4.8000906@gmail.com>
Date: Tue, 1 Mar 2016 11:33:08 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <DB.E1.07778.3D165D65@pb1.pair.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC Proposal] var keyword deprecation/removal
From: rowan.collins@gmail.com (Rowan Collins)

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]