Everything

php

[RFC] Accessors v1.1 -> v1.2 Summary

php.internals

Clint M Priest

13 years ago

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

Amaury Bouchard

13 years ago

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>

Pierre Joye

13 years ago

On Sat, Oct 20, 2012 at 1:06 AM, Clint Priest <cpriest@zerocue.com> wrote:

> 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

Clint M Priest

13 years ago

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

Pierre Joye

13 years ago

On Sat, Oct 20, 2012 at 4:39 PM, Clint Priest <cpriest@zerocue.com> wrote:

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