Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:23311
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <005101c675df$20627cc0$88051fac@OHRLVN4523SG>
To: <jason@ionzoft.com>
Cc: <internals@lists.php.net>
References: <785810036.20060511193536@ionzoft.com> <7.0.1.0.2.20060512082920.040b4040@zend.com>
Date: Fri, 12 May 2006 09:14:20 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="iso-8859-1";
	reply-type=response
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] private, protected, readonly, public
From: pollita@php.net ("Sara Golemon")

>>   __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