Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:23439
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <7.0.1.0.2.20060515190856.02b53bb0@zend.com>
Date: Mon, 15 May 2006 19:12:20 -0700
To: Jason Garber <jason@ionzoft.com>,Zeev Suraski <zeev@zend.com>
Cc: internals@lists.php.net
In-Reply-To: <1217741491.20060515174322@ionzoft.com>
References: <785810036.20060511193536@ionzoft.com>
	<7.0.1.0.2.20060515210559.06acd350@zend.com>
	<1217741491.20060515174322@ionzoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: Re: [PHP-DEV] private, protected, readonly, public
From: andi@zend.com (Andi Gutmans)

Would a method be able to return a writable reference of this 
readonly property? If not it'd actually be PITA to prevent this. This 
is one of those questions which can turn a two second patch by 
Marcus, to an ongoing patch where we continue to fix various places 
and continue to bloat the language and make it much harder to 
maintain (& possibly create new inconsistencies).
So I suggest that before we run forward it has to be clear exactly 
what the semantics would be and in what cases it might fail. Then we 
should consider whether we adopt or reject the idea.
Not saying it's a bad idea but as I've said many times in the past, 
running ahead with an idea like this, without thinking through the 
implications and edge case semantics is a problem...

At 02:43 PM 5/15/2006, Jason Garber wrote:
>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
>
>--
>PHP Internals - PHP Runtime Development Mailing List
>To unsubscribe, visit: http://www.php.net/unsub.php