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:
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.
Sunday, May 14, 2006, 11:05:29 AM, you wrote:
Sunday, May 14, 2006, 4:34:03 AM, you wrote:
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?
Saturday, May 13, 2006, 5:27:34 AM, you wrote:
MB>>>>> Hello Etienne,
MB>>>>> Friday, May 12, 2006, 2:11:38 PM, you wrote:
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);'
<?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.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
http://www.php.net/unsub.php