Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:23329
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Date: Sat, 13 May 2006 11:34:35 +0200
Reply-To: Marcus Boerger <helly@php.net>
Message-ID: <93526366.20060513113435@marcus-boerger.de>
To: Sara Golemon <pollita@php.net>
Cc: jason@ionzoft.com, internals@lists.php.net
In-Reply-To: <005101c675df$20627cc0$88051fac@OHRLVN4523SG>
References: <785810036.20060511193536@ionzoft.com> <7.0.1.0.2.20060512082920.040b4040@zend.com> <005101c675df$20627cc0$88051fac@OHRLVN4523SG>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] private, protected, readonly, public
From: helly@php.net (Marcus Boerger)

Hello Sara,

  while all what you wrote is doable i'd suggest a slightly different
approach. If the name of the variable is prefixed with "r_" and written
from outside the class an error will be issued.

There's only one thing to be considered. The proposal cannot work for
overloaded internal objects like those in ext/dom for example.

Friday, May 12, 2006, 6:14:20 PM, you wrote:

>>>   __get() and __set() are great, but 90% of the time, I find myself
>>>   using them to create public readonly properties.
>>>
>>I can see where it could come in handy but I honestly think it'd be bloat.
>> We have to relax with the OO features because the increased code size has 
>> already made it harder to maintain and it has the potential to make PHP 
>> far more complicated than what it should be.
>>
> An extension could accomplish this by exporting an interface which overrides
> the object's read_property() method.  One could "flag" which properties are 
> allowed to be accessed r/o by giving them a distinct name e.g.:

> class foo implements ReadOnlyProperties {
>     private $__ro__bar;
>     function __construct($val) {
>         $this->__ro__bar = $val;
>     }
> }

> $f = new foo(123);
> var_dump($f->bar);

> The special getter sees that bar isn't in the properties table and looks for
> __ro__bar instead (overriding visibility restrictions in the process). 
> Since there's no write_property override, the prop remains unwritable from 
> outside of the object.

> -Sara 




Best regards,
 Marcus