I have to say that in second thought (after realizing what you really
meant) it sounds like a very useful feature.
The main thing that worries me is the complexity to the end user,
which is already in a pretty bad shape as it is today, and many
people here care very little about it, because they can't relate to
beginners and average developers. Private/protected/public is a
challenge to many of them (not the theory, real world situations),
doubling complexity with a modifier is not a good idea.
In order to push complexity down I'd avoid making this yet another
modifier, and in fact make this an access level, on par with
private/protected/public, that would behave like public, except for
when outside the object scope (i.e., have it between protected and
public). One of the trickey things would be finding an acceptable
name, since 'readonly' implies something which this variable isn't
(it's very much writable, from the right places). Maybe something
like 'visible' (of course preferably we need to find something that
begins with 'p'...)
Zeev
At 02:35 12/05/2006, Jason Garber wrote:
Hello internals,
__get() and __set() are great, but 90% of the time, I find myself
using them to create public readonly properties.
The only problem with this is it is horridly inefficient, consuming
at least 1 function call and one switch statement (or equiv) per
property read.
Would it be possible to create a new object property attribute:
readonly
class xx
{
readonly $bar;
}
$o = new xx();
$o->bar = 10;
>>> FATAL ERROR
This way, PHP would allow reading (as if it were public), but only
allow writing from within the class.
I think it could really boost performance of complicated application
logic that wishes to enforce good visibility.
Comments?
PS. What brought this up was some serious performance issues in a
piece of code that I am working with - most of which can be tied
back to __get() performance.
--
Best regards,
Jason Garber mailto:[EMAIL PROTECTED]
IonZoft, Inc.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
