This is absolutely true. Besides, adding a new access level automatically implies that you'll probably never be able to extend it to protected as well, because you'd need yet another access level and I really doubt people are going to want to do that. But at that point, it would be too late to revert back to a readonly keyword, since the whole world is using the new publicly readable access level already. Choosing to go for a new access level can turn out to be a really big mistake in the long run.
Like you, I don't see why a 'readable' keyword should make things any more complicated for beginners, because indeed, it is optional and beginners will simply not use it. To me, this only shows the strength of PHP: suitable for beginners and suitable for the enterprise. Ron "Jason Garber" <[EMAIL PROTECTED]> schreef in bericht news:[EMAIL PROTECTED] > 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
