Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:23320
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <4464FAC0.5050704@fission.org.uk>
Date: Fri, 12 May 2006 22:14:40 +0100
User-Agent: Thunderbird 1.5 (X11/20060309)
MIME-Version: 1.0
To: Etienne Kneuss <colder@php.net>,  internals@lists.php.net
References: <785810036.20060511193536@ionzoft.com> <44647B7A.2070301@php.net> <4464C4AA.8020102@php.net> <4464F915.7080703@php.net>
In-Reply-To: <4464F915.7080703@php.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] private, protected, readonly, public
From: gareth@fission.org.uk (Gareth Ardron)

Etienne Kneuss wrote:
> Yes, I also consider the visibility as a candy functionality.
>
>   
>> Etienne Kneuss wrote:
>>     
>>> 2) It only requires a bit of discipline, not to edit the properties you
>>> want to be readonly.
>>>       
>> well, then we don't need private/protected/public at all,
>> as it only requires a bit of discipline not to access the
>> properties you want to be visible to the class or its
>> children only? 
>>     

It's only candy functionality when you're not in a position of possibly 
having to hand the application you've written over to a bunch of 
developers you don't know, who probably won't read the docs and will do 
things the wrong way.

Having visibility in this case really, really helps - and more than 
anything, it covers my back when they screw up. Yeah, if all you're 
writing is small apps, you're not going to have an issue - or if you're 
only using a handful of developers, it won't be an issue, but it's a 
very good thing when the future development cycle of a product isn't clear.