private, protected, readonly, public

hehe, maybe confused with delphi or borlands c++ additons? Speaking
of
which before we add 'readonly' we should go for full property support
but
on the other hand that might be a little bit too much until php is used
with code generators and gui designers where code inspectors execute
and
manipulate source/code while developing.

Hi Marcus,

Full property support is high on my wishlist for 6.0. I was a Delphi
programmer for 5 years and miss properties. C#, Ruby, and Java all
have built in property support with accessor methods, or at least a
single standard implementation that all the tools can get behind.
__get and __set leave you in complete limbo for both source code and
reflection based tools. I think the language support has to come
before the tools.

I think this can be implemented by adding a getter and setter field to
zend_property_info, then checking for it in zend_std_read_property,
etc. Although, I'm sure there's more to it than that. Such an
implementation would probably be 3 to 4 times faster than __get(). No
switch, no $name parameter, perhaps no guard logic. Checking for a
getter or setter in zend_property_info would be a fast boolean test on
a data structure thats already available, so I believe there would be
little overhead.

Here are a few use cases and syntax suggestions...

A. Declaring a property with accessor methods:

public $foo read getFoo write setFoo;

B. Read only property with accessor method could be declared:

public $foo read getFoo;

C. A shortcut notation could automatically generate the accessor method
based on another property:

public $foo read $_foo;
// internally generated method ala C# property implementation:
// public function __get_foo() { return $this->$_foo; }

D. Similar to read only, you could have split visibility, for example,
a public getter and a protected setter:

public $foo read getFoo write protected setFoo; // Handy use case, not
crazy about this syntax
public function getFoo() { return $this->_foo; }
protected function setFoo($value) { $this->_foo = $value }

E. To avoid warnings, declare the internal storage, too:

public $foo read $_foo write setFoo, protected $_foo;
public $foo read $_foo, protected $_foo; // readonly

F. Properties with accessor methods cannot be directly initialized.
Their internal storage can, however:

public $foo read $_foo write setFoo, protected $_foo = 'bar';

G. calling unset() on a property with accessor methods could call the
setter with NULL.

H. calling isset() on a property with accessor methods returns FALSE if
the property does not exist, otherwise calls the getter and compares
against NULL for compatibility purposes. (?)

I. calling property_exists() on a property with accessor methods would
always return TRUE.

J. The setter and getter could be inspected via ReflectionProperty.

K. Unlike __get, subclass property definitions could override the
parent declarations:

class Foo { public $prop; }
class Bar extends Foo { public $prop read getProp write setProp; ... }

L. An abstract class need not declare the actual accessor methods, they
could be added as abstract by default:

abstract class Bar { public $foo read getFoo write setFoo; }

Just a few thoughts. I am sure there are other possibilities for the
same use cases.

Best Regards,

Jeff

Likely Delphi yeah :)

Ron

"Marcus Boerger" helly@php.net schreef in bericht
news:1771237045.20060514011813@marcus-boerger.de...

Hello Ron,

hehe, maybe confused with delphi or borlands c++ additons? Speaking of
which before we add 'readonly' we should go for full property support but
on the other hand that might be a little bit too much until php is used
with code generators and gui designers where code inspectors execute and
manipulate source/code while developing. Ups wrong tool....

regards
marcus

Saturday, May 13, 2006, 8:52:39 PM, you wrote:

My bad, you are absolutely right, I must be confused with another
language,
but I wonder which one.... odd.

Ron

"Hartmut Holzgraefe" hartmut@php.net wrote in message
news:4465FBED.8070205@php.net...

Ron Korving wrote:

In C++ you'd use private for this. All object members are readable,
...

Could you elaborate on this?

--
Hartmut Holzgraefe, Senior Support Engineer .
MySQL AB, www.mysql.com

Are you certified? http://www.mysql.com/training/certification

Best regards,
Marcus

It seems to me this would be a great option to add. How difficult would it
be? Would it take significant editing of the source code? I don't see the
issue in adding it - seems like it would have plenty of places to be used.
Though, if it is added, the name 'readonly' seems a little misleading. It
gives off the idea of being able to set it, and not edit again, and not only
being able to edit it inside the class.

Bastian Grupe wrote:

Blame my recent use of Java here ;-)

Well, I think the whole point of ppp is to having to use setters and
getters consistently.

i'm going to blame your use of Java for this one, ppp is way older
than the setter/getter fashion and as far as i remember the main
reason to introduce the setter/getter pattern into java was to
have a standard way for Java IDEs to provide access to Java Bean
properties in property dialogs in their GUI design tools

I personally wouldn't like to be able to access some members which are
private, and not others. It just feels wrong.

Think of it as a more fine grained permission system, like unix
file attributes. Reading and writing a property value are two
different operations and it makes sense to distinguish access
rights not only by ownership but also by type of operation.

And I don't know whether or not less typing is really a good argument in
this situation (think unreadable code in shortcut-ish programming
languages).

Less typing is not an argument by itself, else we'd all do APL

But less typing is less error prone (and no, plese don't mention
auto-completion here ;), it can be less readable, too, and in this
special case it spreads information that should be in one place.
Maintainability can become an issue, too.

Take a look at typical PHP class implementations: they have
all properties on top followed by the member functions. So to find
out whether a private property is really provite or whether it has
a getter or even a setter, too, i would have to browse the full
class code.

class example {
private $foo;
private $bar;
[... more properties ...]

 function __construct() {...}
 function __destruct() {...}

 function getFoo() {...}

 [... more code ...]

}

So $foo is readonly here and $bar is really private. Or wait,
maybe we have just overlooked getBar()?

With

readonly $foo;

on the other hand you have all the information in one place.

If you want to go the getter/setter path all the way then we
wouldn't need all the ppp stuff anymore alltogether, we would
just make everything private and have the getter and setter
decide (using instanceof on $this etc.) the access rights.

--
Hartmut Holzgraefe, Senior Support Engineer .
MySQL AB, www.mysql.com

Are you certified? http://www.mysql.com/training/certification

--

--

Graham Christensen
www.itrebal.com
www.iamgraham.net

Hello Andi,

however the past has tought of something. Nobody will test a patch.
That said there won't be any feedback until it gets into at least head
and people feel confident they should experiment with it. As it stands
now you could just take it as a decision against it and be done.

best regards
marcus

Tuesday, May 16, 2006, 10:39:53 PM, you wrote:

I suggest to wait for a response about the edge cases question I sent
out (i.e. returning a writable reference of this readonly property).

How is a writeable reference a public read variable in php? In php we
don't have concept like c++ offeres and even there normally const methods
return const references aka read only references.

I for one haven't quite understood what the semantics will be in all
the edge case situations.

The semantics for the majority seems to be public read. E.g. the language
offers a way to circumvent or redefine visibility when reading.

Although I think the concept is interesting
(and somewhat beneficial), I don't want to regret having done it 6
months down the line when people complain it's broken because in edge
cases it doesn't work. We need to be sure that the semantics are 100%
ok in all cases. Writing a patch is the easy part.

If that was the case, then why was i the only one to provide a patch like
in so many times before. I mean yes it is easy for me, and definitively also
for dmitry and sara as well as most likely for you too. But how mayn other
people can provide such a patch?

The fact that
patches can be written doesn't mean we shouldn't be careful about
making these changes. We have made too many mistakes in the past
which were hard to undo.

Yes we have only i don't know what we can really do about. I mean other
then discussiong it, see that it is doable and getting a feeling for it?
We can apply it or forget it.

best regards
marcus

p.s.: I still have the patches for public/protected/private and those for
final and tons of others related to our object model. Want me to use them
to drop any feature? :-))

"Zeev Suraski" zeev@zend.com schreef in bericht
news:7.0.1.0.2.20060516133953.09045a30@zend.com...

...
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

I don't need this feature, so I'm not suggestion anything just because I'd
prefer it that way myself. I'm perfectly happy writing setters and getters.
The only reason of my post was that I anticipate disappointment in the long
run when, as you confirm yourself, "readonly protected" will become
practically impossible (besides which, going beyond ppp just seems a little
ugly, but I'm sure that's just a matter of taste).

I don't really see the huge deal in that a beginner has to be able to
understand every bit of code. That same problem exists with other languages
where beginners will have big problems diving into complex code (very much
including syntax related complexity, like with c++ templates, macros, ...).

The only thing I fear is disappointment in the long run really, because an
irriversible unlucky decision was made (magic quotes, parameter order of
certain functions).

In fact, if you want the easiest solution, I actually think the wrong idea I
had about c++ access levels could prove to be useful:

What if access levels only mean anything to writing to data members, while
all data members are publicly readable?

<?php

class Foo
{
private $bar = 5;
}

$foo = new Foo();
echo $foo->bar; // prints 5
$foo->bar = 4; // error

?>

I think backwards compatibility would likely be alright, performance will be
fine, there will be no extra keyword, no extra access level, and no need for
getter functions. Just an idea.

Regards,

Ron

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.

Hello Andi, hello List,

this patch does not introduce a new keywors and thus comes with a whole
set of problems canceled out already. 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. 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 :-)

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.

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.

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