Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:23450
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <7.0.1.0.2.20060516133953.09045a30@zend.com>
Date: Tue, 16 May 2006 13:57:00 +0300
To: "Ron Korving" <r.korving@xit.nl>
Cc: internals@lists.php.net
In-Reply-To: <89.E7.19568.50199644@pb1.pair.com>
References: <785810036.20060511193536@ionzoft.com>
	<7.0.1.0.2.20060515210559.06acd350@zend.com>
	<1217741491.20060515174322@ionzoft.com>
	<89.E7.19568.50199644@pb1.pair.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: Re: [PHP-DEV] private, protected, readonly, public
From: zeev@zend.com (Zeev Suraski)

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" <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
>
>--
>PHP Internals - PHP Runtime Development Mailing List
>To unsubscribe, visit: http://www.php.net/unsub.php