Ron,
As I've said numerous times in the past, it's not about what
beginners use or not, it's about whether it's in the language or not.
Additional keywords and structures make the language more
complicated. It's an axiom. Look at PHP 5 books vs. PHP 4 books,
including books for beginners. All of them cover everything, and for
a good reason - in the PHP world, you need to be able to understand
other people's code at least as much as you have to be able to create
new code yourself. Every new construct, every new access level or
modifier - become a standard part of the basic-elements that PHP
developers have to understand and be aware of. So the 'beginners
won't use it' argument simply doesn't hold water, as it will confuse
them irregardless. I'm seeing that in practice, in places far, far
away from internals@, and there are definitely doubts and worries
amongst PHP developers regarding the complexity&purity directions
that PHP appears to be taking. Most of the people I talk with are
mostly happy with PHP 5 (although there are those who think that PHP
5 already went too far), but a lot of them say that we should not go
any further in order to preserve the simplicity.
Now, all that said, I'm not certain what's the best option here. In
terms of complexity, clearly not adding this modifier is the best
approach. There's also the issue Andi mentioned, of the feasibility
of creating this patch and maintaining it in an acceptable
manner. Assuming we all agree to live forever with the semantics
that can be implemented, I for one think it's actually a fairly
useful feature, including very much for beginners.
Regarding whether it's an access level or a modifier, I think that an
access level is better since you don't have to explain a matrix of 6
different behaviors (including one that doesn't make sense, but still
requires an explanation), only one more access level. I think we can
definitely give up the equivalent of 'readonly protected', and tell
people to use protected and restrain themselves in those rare cases
where it's needed and use regular protected or __set(). When we make
this decision, though, it means that we won't be adding the
equivalent of 'readonly protected' in the future either, including
when people come along and present a use case where it'd be great to use it.
Zeev
At 11:44 16/05/2006, Ron Korving wrote:
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
