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