Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:23472
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <7.0.1.0.2.20060516235201.090f10a8@zend.com>
Date: Wed, 17 May 2006 00:08:57 +0300
To: Marcus Boerger <helly@php.net>
Cc: Andi Gutmans <andi@zend.com>,PHP internals <internals@lists.php.net>
In-Reply-To: <1562034641.20060516203354@marcus-boerger.de>
References: <785810036.20060511193536@ionzoft.com>
	<44647B7A.2070301@php.net>
	<932738738.20060513112734@marcus-boerger.de>
	<837405862.20060513223403@ionzoft.com>
	<36828701.20060514110529@marcus-boerger.de>
	<31269879.20060514221212@marcus-boerger.de>
	<1327845846.20060514222154@marcus-boerger.de>
	<1562034641.20060516203354@marcus-boerger.de>
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)

At 21:33 16/05/2006, Marcus Boerger wrote:
>Hello Andi, hello List,
>
>   this patch does not introduce a new keywors and thus comes with a whole
>set of problems canceled out already.

I think that it's absolutely horrible syntax wise :)  private:public $foo?

>  Anyway it adds complexity to what you
>have to learn about PHP. In fact seeing two visibility keywords separated
>by a colon should be easy enough to understand for everybody.

I'll be blunt as it's late here, but that's just ******** (decided to 
censor myself).  I for one would never guess what it means (well 
actually my guess would be something to do with inheritance).  Either 
I'm an idiot, or you have a serious problem estimating what's obvious 
and what's not...  And before you say anything, no, I'm not an idiot :)

>But noone
>would know which side is the read and which is the write side. The keyword
>'readable' on the otherhand would be absolutly clear even for beginners
>after at least thinking for a second. But oh i said thinking :-)

Again, ******** in my humble opinion.  Readable from where?  Does it 
mean it's otherwise not readable?  Does it mean that it's not 
writable?  From where?  How does it relate to inheritance?

There's no way in hell to understand it without reading up on it, 
and  even then, it's not very easy to remember.

You've seen today someone saying that PPP is often tricky as it 
is.  So those 'horror stories' I'm telling are very much a 
reality.  You're suggesting that doesn't complicate it further?  Please.

>The patch also allows any combinations in later version should we ever want
>to go that road which i do not see any sense in. E.g. private:public and
>protected:public make sense to me and are often a nice optimization and
>also a nice shortcu in development and easing the pain especially for
>beginners or small hacked to gether stuff.

Look, don't get me wrong, but if you pursue this private:public 
thingie, I'll have to hurt you next time I see you :)  Just no way.

>However, the reason i write this mail is that you said there could be
>problems. Well this is deply integrated  in the handlers and they don't
>let you out. In other words if this stuff is not working then the whole
>PHP 5+ object model is broken. Or in other words, if this is broken alot
>of other stuff regarding object handling is already broken.

You're probably right about this one.  You can already return a 
reference to a private variable today and change it.  Andi - did you 
mean something else?

Zeev

>best regards
>marcus
>
>btw, i wonder where the people are that usually complain about my patches?
>Is this finally something most people like?
>
>Sunday, May 14, 2006, 10:21:54 PM, you wrote:
>
> > Hello internals,
>
> >   sorry the patch got lost somehow, here it is :-)
>
> > regards
> > marcus
>
> > Sunday, May 14, 2006, 10:12:12 PM, you wrote:
>
> >> Hello guys,
>
> >>   after some incantations i came to the attached improved patch that
> >> allows to give properties any visibility plus mark them as public
> >> readable. The patch also implements the PHP 6.0 todo item 'readonly
> >> for overloaded objects'.
>
> >> The code now looks like:
> >> <?php
> >> class Test {
> >>   private:public $x = 42;
> >> }
>
> >> $obj = new Test;
> >> var_dump($obj->x);
>?>>>
>
> >> Note, that this adheres to the following EBNF:
>
> >> <property>     := <write_access>+ (':' <read_access>)? '$' <name> ';'
> >> <write_access> := 'var' | 'public' | 'protected' | 'private'
> >> <read_access>  := 'public'
> >> <name>         := [_a-zA_Z][_a-zA_Z0-9]*
>
> >> Adding 'protected' to <read_access> is possible to but code wise a
> >> tiny bit more complex. Chaging the order is of cause also possible.
>
> >> best regards
> >> marcus
>
> >> Sunday, May 14, 2006, 11:05:29 AM, you wrote:
>
> >>> Hello Jason,
>
> >>> Sunday, May 14, 2006, 4:34:03 AM, you wrote:
>
> >>>> Hello Marcus,
>
> >>>>   class x
> >>>>   {
> >>>>      public readonly $xyz;
> >>>>      protected readonly $abc;
> >>>>   }
>
> >>>>   Definitions:
> >>>>   - public readonly    - outside class can only read, not write.
> >>>>   - protected readonly - subclass can only read, not write.
> >>>>   - private readonly   - does not make sense - do not support.
>
> >>>>   How difficult would it be to build this into the PHP engine?
>
> >>>> --
> >>>> Best regards,
> >>>>  Jason                            mailto:jason@ionzoft.com
>
> >>>> Saturday, May 13, 2006, 5:27:34 AM, you wrote:
>
>MB>>>>> Hello Etienne,
>
>MB>>>>> Friday, May 12, 2006, 2:11:38 PM, you wrote:
>
> >>>>>> Hi,
>
> >>>>>> my 2c:
>
> >>>>>> 1) it shouldn't replace the visibility definition: we could also have
> >>>>>> protected readonly properties.
>
>MB>>>>> same here visibility and read/write control are two seperate things.
>
> >>>>>> 3) how would you check if the property if readonly ? Trying it could
> >>>>>> result to a Fatal error as you wanted. You would then need a
> >>>>>> isReadonly() method/function: the function call wouldn't be spared.
>
>MB>>>>> We could add this to reflection api easily.
>
> >>> Here's your diff to play around :-)
> >>> The impact on runtime is a single additional integer check for protected
> >>> properties and  an additional check for private proeprties where property
> >>> access would normally fail. For this 5 minute patch i chose the key word
> >>> 'readonly' as supposed. Actually writing the mail took much longer than
> >>> brewing the patch and yes i din't care for syntax right now.
>
> >>> php -r 'class T{private readonly $x = 42;} $obj = new T; 
> var_dump($obj->x);'
> >>> int(42)
>
> >>> Or readable:
>
> >>> <?php
> >>> class Test {
> >>>   private readonly $x = 42;
> >>> }
>
> >>> $obj = new Test;
> >>> var_dump($obj->x);
>?>>>>
>
> >>> As we have the 'Property overloading RFC' on the 6.0 aganda
> >>> we should probably move part of the stuff to 5.2 already and
> >>> start with the public read access.
>
> >>> http://oss.backendmedia.com/PhP60
> >>> http://www.zend.com/zend/week/week248.php#Heading3
>
>--
>PHP Internals - PHP Runtime Development Mailing List
>To unsubscribe, visit: http://www.php.net/unsub.php