Hello Zeev, In the same way that public readonly properties would be useful from the global scope, protected readonly properties would be just as useful to those of us who spend their php-lives writing base classes (like me) for others to extend and use.
I would imagine that the Zend Framework will encounter the (performance based) need for this eventually - I already have. That being said, an access level that means "public readonly" would be very good - but taking it the whole way would be a lot better. Considering that it is an optional keyword, and will only be used where __get(), __set() used to be used - it won't confuse the end users who do not care about it. (get/set is a lot more complex). Thanks! -- Best regards, Jason mailto:[EMAIL PROTECTED] Monday, May 15, 2006, 2:15:50 PM, you wrote: ZS> I have to say that in second thought (after realizing what you really ZS> meant) it sounds like a very useful feature. ZS> The main thing that worries me is the complexity to the end user, ZS> which is already in a pretty bad shape as it is today, and many ZS> people here care very little about it, because they can't relate to ZS> beginners and average developers. Private/protected/public is a ZS> challenge to many of them (not the theory, real world situations), ZS> doubling complexity with a modifier is not a good idea. ZS> In order to push complexity down I'd avoid making this yet another ZS> modifier, and in fact make this an access level, on par with ZS> private/protected/public, that would behave like public, except for ZS> when outside the object scope (i.e., have it between protected and ZS> public). One of the trickey things would be finding an acceptable ZS> name, since 'readonly' implies something which this variable isn't ZS> (it's very much writable, from the right places). Maybe something ZS> like 'visible' (of course preferably we need to find something that ZS> begins with 'p'...) ZS> Zeev ZS> 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
