Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:23447
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <89.E7.19568.50199644@pb1.pair.com>
To: internals@lists.php.net
References: <785810036.20060511193536@ionzoft.com> <7.0.1.0.2.20060515210559.06acd350@zend.com> <1217741491.20060515174322@ionzoft.com>
Date: Tue, 16 May 2006 10:44:41 +0200
Lines: 111
Subject: Re: [PHP-DEV] private, protected, readonly, public
From: r.korving@xit.nl ("Ron Korving")

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" <jason@ionzoft.com> schreef in bericht 
news:1217741491.20060515174322@ionzoft.com...
> 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:jason@ionzoft.com
>
> 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:jason@ionzoft.com
>>>  IonZoft, Inc.
>>>
>>>--
>>>PHP Internals - PHP Runtime Development Mailing List
>>>To unsubscribe, visit: http://www.php.net/unsub.php