Hey everyone, seems like the conversations have died down and I've attempted to go back through all of the emails and produce a 1.1 -> 1.2 document which summarizes what I believe are decided, being debated, issues, todos, etc.
Pierre had pointed out that I had partially changed the "as-implemented" document which no longer reflected what the fork implements. So... I have reverted that document to the 1.1 version.
For the TODO items I will start to tackle those which are not dependent upon some undecided changes.
https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented/change-requests
Please take a look and lets continue the discussion.
Lastly, in order to keep the discussions of this large change, can we keep/maintain separate threads discussing each of the major points? For example if you want to talk about the "internal accessor method visibility", create an email chain like "Accessors v1.2 : internal accessor method visibility"
Hopefully we can keep the emails in each thread on topic.
Thanks!
-Clint
read-only / write-only keywords
"no equivalent replacement has been suggested" => ouch
read-only => const
write-only => shouldn't exists. A write-only accessor is just a method
disguised in property.
It's not a good idea to allow:
$obj->prop = 3;
when the meaning is:
$obj->meth(3);
2012/10/20 Clint Priest cpriest@zerocue.com
Hey everyone, seems like the conversations have died down and I've
attempted to go back through all of the emails and produce a 1.1 -> 1.2
document which summarizes what I believe are decided, being debated,
issues, todos, etc.Pierre had pointed out that I had partially changed the "as-implemented"
document which no longer reflected what the fork implements. So... I have
reverted that document to the 1.1 version.For the TODO items I will start to tackle those which are not dependent
upon some undecided changes.https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented/change-requests
Please take a look and lets continue the discussion.
Lastly, in order to keep the discussions of this large change, can we
keep/maintain separate threads discussing each of the major points? For
example if you want to talk about the "internal accessor method
visibility", create an email chain like "Accessors v1.2 : internal accessor
method visibility"Hopefully we can keep the emails in each thread on topic.
Thanks!
-Clint
Hey everyone, seems like the conversations have died down and I've attempted to go back through all of the emails and produce a 1.1 -> 1.2 document which summarizes what I believe are decided, being debated, issues, todos, etc.
Pierre had pointed out that I had partially changed the "as-implemented" document which no longer reflected what the fork implements. So... I have reverted that document to the 1.1 version.
You can use branches as well, and refer to them in the RFC. Going back
and forth and loosing track or ability to test a given feature or
option is not that good to evaluate the choices :)
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
The problem was that the RFC had been updated past where the code was, AFAIK you can't branch a wiki page, can you? That's what needed branching... unless you mean to create a v1.1 page and a v1.2 page, which is basically what I've done...
-----Original Message-----
From: Pierre Joye [mailto:pierre.php@gmail.com]
Sent: Saturday, October 20, 2012 5:16 AM
To: Clint Priest
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] Accessors v1.1 -> v1.2 SummaryHey everyone, seems like the conversations have died down and I've attempted to go back through all of the emails and produce a
1.1 -> 1.2 document which summarizes what I believe are decided, being debated, issues, todos, etc.Pierre had pointed out that I had partially changed the "as-implemented" document which no longer reflected what the fork
implements. So... I have reverted that document to the 1.1 version.You can use branches as well, and refer to them in the RFC. Going back and forth and loosing track or ability to test a given feature or
option is not that good to evaluate the choices :)Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
The problem was that the RFC had been updated past where the code was, AFAIK you can't branch a wiki page, can you? That's what needed branching... unless you mean to create a v1.1 page and a v1.2 page, which is basically what I've done...
I mean in git. The RFCs can then contain the options, it could be
useful to have two versions at a time to compare them. I don't think
we need to have many pages for this RFC.