# [RFC] Accessors v1.1 -> v1.2 Summary - Thread: https://externals.io/message/63547 - Original archive: https://news-web.php.net/php.internals/63547 - Started by Clint Priest on 2012-10-19T23:06:15+00:00 - Messages: 5 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #63547 — Clint Priest — 2012-10-19T23:06:15+00:00 URL: https://externals.io/message/63547#63547 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 --- ## #63550 — Amaury Bouchard — 2012-10-20T08:09:35+00:00 URL: https://externals.io/message/63547#63550 · In reply to: #63547 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 > 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 --- ## #63560 — Pierre Joye — 2012-10-20T10:16:19+00:00 URL: https://externals.io/message/63547#63560 · In reply to: #63547 > 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 --- ## #63565 — Clint Priest — 2012-10-20T14:39:35+00:00 URL: https://externals.io/message/63547#63565 · In reply to: #63560 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 Summary > > > > […] > 1.1 -> 1.2 document which summarizes what I believe are decided, being debated, issues, todos, etc. > > […] > 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 --- ## #63566 — Pierre Joye — 2012-10-20T14:40:45+00:00 URL: https://externals.io/message/63547#63566 · In reply to: #63565 > 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.