# [VOTE] Automatic Property Initialization

- Thread: https://externals.io/message/71886
- Original archive: https://news-web.php.net/php.internals/71886
- Started by gooh on 2014-01-31T19:18:50+00:00
- Messages: 33
- Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL)
- Next page: https://externals.io/message/71886.md?page=2
- 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

---

## #71886 — gooh — 2014-01-31T19:18:50+00:00

URL: https://externals.io/message/71886#71886

Hi,

I've opened the voting for Automatic Property Initialization:

- https://wiki.php.net/rfc/automatic_property_initialization

There was little feedback on internals regarding this RFC but the few 
responses that have been made were generally in favor of this feature. 
The notable and understandable exception being the HHVM team that would 
prefer their own implementation of constructor promotion. No particular 
extra features have been rejected or strongly favored, which is why I am 
excluding from the vote.

Voting will be on the patch supplied by NikiC. So you are solely voting 
on allowing $this->foo as constructor arguments. None of the other 
suggested features in the RFC are subject to vote.

Voting ends on 2014/02/10 01:00 UTC

Cheers, Gordon
-- 
http://about.me/gooh

---

## #71895 — johannes@schlueters.de — 2014-01-31T21:30:04+00:00

URL: https://externals.io/message/71886#71895 · In reply to: #71886

> Hi,
> 
> I've opened the voting for Automatic Property Initialization:
> 
> - https://wiki.php.net/rfc/automatic_property_initialization

This has the same issue as the 64bit RFC:
"This feature is proposed for inclusion in PHP 5.6"

For 5.6 we have an alpha out. We created a new release process after
learning that changes late in the game delay our releases and offer a
stronger guarantee that the following release is not in unforeseeable
future to make it a viable thing to delay changes by a release.

This is no evaluation of the feature itself.

johannes

---

## #71905 — Robert Parker — 2014-01-31T23:09:31+00:00

URL: https://externals.io/message/71886#71905

> Le 31/01/2014 22:30, Johannes Schlüter a écrit :
> > […]
> 
> Hi Johannes,
> 
> Out of curiosity I read both the Voting and Release Process RFCs and
> couldn't find any mention of a rule stating that all votes had to be
> approved before the first alpha, if I overlooked it, please correct
> me. Also, If you look at the wikipedia definition of an alpha in, I
> believe that it is still time to add features:
> 
> <quote>The alpha phase usually ends with a feature freeze, indicating
> that no more features will be added to the software. At this time, the
> software is said to be feature complete.</quote>
> http://en.wikipedia.org/wiki/Software_release_life_cycle#Alpha
> 
> Also, isn't it to the Release Manager role to make such decisions?
> 
> I digged the archives from last month and I found this message from
> Ferenc Kovacs and Julien Pauli who are RMs:
> 
> <quote>
> Yep, that's to prepare for the future.
> We *won't* merge any RFC after the first beta. Recall that everybody.
> 
> If you now have a new RFC, ok why not accept it in the 5.6 workflow
> (even if we said no new RFC after first alpha) , let's not be too
> strict, but be warned it *has to* be merged before first beta , that
> is something like mid-march.
> For sure, no new idea can be merged after first beta, so RFC will have
> to be stabilized and voted and accepted for the mid-march dead-line.
> </quote>
> 
> The document linked is:
> https://wiki.php.net/todo/php56#timetable
> 
> The RFC was created before the first alpha, the voting phase is now
> and if the result of the vote is a yes, then it has until mid-March to
> be included. At least that's how I read it.
> 
> I am just a reader of the list, I unfortunately don't have the skills
> to participate at this level of technicity, but maybe it would be good
> for you guys to clarify the schedule and especially clarify the voting
> process in this schedule since apparently you understand the 'No new
> RFC' by alpha 1' as 'Only RFCs that got a positive vote before alpha 1
> can be in the final realease'. I think it's probably the role of RMs
> to clearly state  what the wording they use means to make sure
> everybody is on the same page.
> 
> My 2 cents,
> 
> Regards :)
> 
> Pascal

I think this should be included but I don't remember there being any 
discussion on this. Will this work with types?

public function __construct((foo) $this->x, (bar) $this->y);

---

## #71906 — johannes@schlueters.de — 2014-01-31T23:13:34+00:00

URL: https://externals.io/message/71886#71906

Hi Pascal,


> Out of curiosity I read both the Voting and Release Process RFCs and 
> couldn't find any mention of a rule stating that all votes had to be 
> approved before the first alpha, if I overlooked it, please correct me. 
> Also, If you look at the wikipedia definition of an alpha in, I believe 
> that it is still time to add features:

No, that rule wasn't written down, but the release process came to live
out of consequence of us pushing things in quite late in the game and I
fear we run exactly in the same direction, again.

> Also, isn't it to the Release Manager role to make such decisions?
[...]
> The document linked is:
> https://wiki.php.net/todo/php56#timetable
[...]
> The RFC was created before the first alpha, the voting phase is now and 
> if the result of the vote is a yes, then it has until mid-March to be 
> included. At least that's how I read it.

Yes, there is no strict rule, but still we're not talking about a small
change here but a language change (a small language change, but still)
and I merely wish that this fact is considered by voters. Ideally the
proposer would have added options for 5.6 and the following version.


(Actually I hadn't reviewed the proposal before and from a quick look at
it there seems to be a design flaw around inheritance with code like
this:
   class Base { public $p; function __construct($this->p = 42); }
   Class E extends Base { function __construct($this->p = 23) { parent::__construct(); }
   new E;
leading to probably unexpected results ... also
   class C { public function m($foo->prop){}}
becomes valid syntax and leads to (fatal) runtime errors, this might
even be true for non-class function declarations ... but I haven't
really checked, I assume voters will)

johannes

---

## #71909 — Dan Ackroyd — 2014-01-31T23:48:09+00:00

URL: https://externals.io/message/71886#71909 · In reply to: #71906

Hi Johannes,

Johannes wrote:
> from a quick look at it there seems to be a design flaw
> around inheritance with code like this:

That example is equivalent to calling the parent constuctor like this:

class Base {
    public $p;

    function __construct($this->p = 42);
}

Class E extends Base {
    function __construct($value) {
        $this->p = $value;
        parent::__construct();
    }
}

So yes - you need will still need to pass parameters to a parent
constructor that requires them, but that is the same as the current
situation.


Johannes wrote:
> also
>   class C { public function m($foo->prop){}}
> becomes valid syntax

Nope, it's constructors only. From the patch, the following errors can
be triggered:

"Automatic property initialization can only be used inside a class"
"Automatic property initialization can only be used in a constructor"
"Automatic property initialization can not be used in an abstract method"

If you try to use the syntax outside of a constructor function.

cheers
Dan

On Fri, Jan 31, 2014 at 11:13 PM, Johannes Schlüter
<johannes@schlueters.de> wrote:
> Hi Pascal,
>
> 
> > […]
>
> No, that rule wasn't written down, but the release process came to live
> out of consequence of us pushing things in quite late in the game and I
> fear we run exactly in the same direction, again.
>
> > […]
> [...]
> > […]
> [...]
> > […]
>
> Yes, there is no strict rule, but still we're not talking about a small
> change here but a language change (a small language change, but still)
> and I merely wish that this fact is considered by voters. Ideally the
> proposer would have added options for 5.6 and the following version.
>
>
> (Actually I hadn't reviewed the proposal before and from a quick look at
> it there seems to be a design flaw around inheritance with code like
> this:
>    class Base { public $p; function __construct($this->p = 42); }
>    Class E extends Base { function __construct($this->p = 23) { parent::__construct(); }
>    new E;
> leading to probably unexpected results ... also
>    class C { public function m($foo->prop){}}
> becomes valid syntax and leads to (fatal) runtime errors, this might
> even be true for non-class function declarations ... but I haven't
> really checked, I assume voters will)
>
> johannes

---

## #71910 — johannes@schlueters.de — 2014-01-31T23:57:41+00:00

URL: https://externals.io/message/71886#71910 · In reply to: #71909

> Hi Johannes,
> 
> Johannes wrote:
> > […]
> 
> That example is equivalent to calling the parent constuctor like this:
> 
> class Base {
>     public $p;
> 
>     function __construct($this->p = 42);
> }
> 
> Class E extends Base {
>     function __construct($value) {
>         $this->p = $value;
>         parent::__construct();
>     }
> }
> 
> So yes - you need will still need to pass parameters to a parent
> constructor that requires them, but that is the same as the current
> situation.

Right. Still one should be aware of this and might be worth adding to
RFC. "Correct" usage would of course be be passing parameters through
explicitly.

> Johannes wrote:
> > […]
> 
> Nope, it's constructors only. From the patch, the following errors can
> be triggered:
> 
> "Automatic property initialization can only be used inside a class"
> "Automatic property initialization can only be used in a constructor"
> "Automatic property initialization can not be used in an abstract method"
> 
> If you try to use the syntax outside of a constructor function.

As said - just had a quick look and didn't think much. if those are
triggered during compilation (which would be obvious as only the
compiler is changed ...) then its fine.
Thanks for reviewing!

johannes

---

## #71915 — Pierre Joye — 2014-02-01T08:57:25+00:00

URL: https://externals.io/message/71886#71915 · In reply to: #71895

On Fri, Jan 31, 2014 at 10:30 PM, Johannes Schlüter
<johannes@schlueters.de> wrote:
> 
> > […]
>
> This has the same issue as the 64bit RFC:
> "This feature is proposed for inclusion in PHP 5.6"
>
> For 5.6 we have an alpha out. We created a new release process after
> learning that changes late in the game delay our releases and offer a
> stronger guarantee that the following release is not in unforeseeable
> future to make it a viable thing to delay changes by a release.

Exactly, however the idea is to give common sense a chance. We
explicitly did not specify that RFCs cannot be accepted after the 1st
alpha but before the beta phase (feature freeze).


> This is no evaluation of the feature itself.

And here I have to agree, language changes (syntax, new language
features, etc.) need much more time to be evaluated correctly. This is
then the RMs role to decide if this evaluation has been done correctly
or not. But I did not check the time plan to see if it is even
possible now to accept any new RFC.

Cheers,
-- 
Pierre

@pierrejoye | http://www.libgd.org

---

## #71916 — Stas Malyshev — 2014-02-01T09:04:19+00:00

URL: https://externals.io/message/71886#71916 · In reply to: #71886

Hi!

> I've opened the voting for Automatic Property Initialization:
> 
> - https://wiki.php.net/rfc/automatic_property_initialization
> 

Please note that this RFC adds actually two features - the $this->foo in
ctor args and functions with empty body described as foo(); - but only
if this function is a constructor. None of other functions can do that.
Which sounds pretty inconsistent to me.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

---

## #71917 — Joe Watkins — 2014-02-01T09:43:20+00:00

URL: https://externals.io/message/71886#71917 · In reply to: #71916

> Hi!
>
> > […]
>
> Please note that this RFC adds actually two features - the $this->foo in
> ctor args and functions with empty body described as foo(); - but only
> if this function is a constructor. None of other functions can do that.
> Which sounds pretty inconsistent to me.
>

 > The patch currently just allow for $this→foo as constructor 
arguments, since this is the desired core functionality. Any of the 
other suggested features, like methodless constructors or alternative 
syntax or using a keyword are subject to discussion. They are not part 
of this patch.

 > The vote is for the current patch. You are solely voting on allowing 
$this→foo as constructor arguments. None of the other suggested features 
in this document are subject to vote.

The patch, and vote, is only for automatic property initialization, not 
methodless constructors.

Cheers
Joe

---

## #71920 — Ferenc Kovacs — 2014-02-01T12:38:41+00:00

URL: https://externals.io/message/71886#71920 · In reply to: #71895

On Fri, Jan 31, 2014 at 10:30 PM, Johannes Schlüter
<johannes@schlueters.de>wrote:

> 
> > […]
>
> This has the same issue as the 64bit RFC:
> "This feature is proposed for inclusion in PHP 5.6"
>
> For 5.6 we have an alpha out. We created a new release process after
> learning that changes late in the game delay our releases and offer a
> stronger guarantee that the following release is not in unforeseeable
> future to make it a viable thing to delay changes by a release.
>
> This is no evaluation of the feature itself.
>
> johannes
>
>
>
> --
> 
> 
>
>
Hi,

Julien and me proposed and agreed that RFCs already in discussion before
the first alpha are allowed to be included if the patch and the voting is
done before the first beta.
See
https://wiki.php.net/todo/php56#timetable
and
http://grokbase.com/p/php/php-internals/13cd1g6zs1/php-dev-proposed-timetable-for-php-5-6-0

-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

---

## #71932 — Sara Golemon — 2014-02-01T19:25:55+00:00

URL: https://externals.io/message/71886#71932 · In reply to: #71886

> I've opened the voting for Automatic Property Initialization:
>
> - https://wiki.php.net/rfc/automatic_property_initialization
>
> There was little feedback on internals regarding this RFC but the few
> responses that have been made were generally in favor of this feature. The
> notable and understandable exception being the HHVM team that would prefer
> their own implementation of constructor promotion. No particular extra
> features have been rejected or strongly favored, which is why I am excluding
> from the vote.
>
FYI, I'm voting "No" as I don't think
https://wiki.php.net/rfc/constructor-promotion was considered
adequately.  They both seek to accomplish the same goal, but one
introduces conflicting syntax while the other does not.

If we're to go with the conflicting syntax, I'd like to see a
reasonable argument why.

-Sara

---

## #71935 — Gordon Oheim — 2014-02-01T19:43:52+00:00

URL: https://externals.io/message/71886#71935 · In reply to: #71932

> 
> > […]
> FYI, I'm voting "No" as I don't think
> https://wiki.php.net/rfc/constructor-promotion was considered
> adequately.  They both seek to accomplish the same goal, but one
> introduces conflicting syntax while the other does not.
>
> If we're to go with the conflicting syntax, I'd like to see a
> reasonable argument why.
>
> -Sara
>
How is it conflicting?

-Gordon

---

## #71936 — Sara Golemon — 2014-02-01T19:53:41+00:00

URL: https://externals.io/message/71886#71936 · In reply to: #71935

> 
> > […]
> How is it conflicting?
>
Because it's different from already existing syntax (Code exists in
the wild using HHVM's version of the syntax -
https://wiki.php.net/rfc/constructor-promotion ).  I'm not sure which
part you're confused about.

-Sara

---

## #71938 — Stas Malyshev — 2014-02-01T19:59:16+00:00

URL: https://externals.io/message/71886#71938 · In reply to: #71917

Hi!

> The patch, and vote, is only for automatic property initialization, not 
> methodless constructors.

If so, the RFC should be cleaned up to reflect what is being voted. I
shouldn't have to apply diffs to RFC to understand what the vote is
about, it should say so in the RFC. If something is not a part of it,
then drop it from the RFC or put it in "Future developments" section.


-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

---

## #71942 — Gordon Oheim — 2014-02-01T21:08:38+00:00

URL: https://externals.io/message/71886#71942 · In reply to: #71938

> Hi!
>
> > […]
>
> If so, the RFC should be cleaned up to reflect what is being voted. I
> shouldn't have to apply diffs to RFC to understand what the vote is
> about, it should say so in the RFC. If something is not a part of it,
> then drop it from the RFC or put it in "Future developments" section.
>
>
Sorry, but I think it's pretty clear what is being voted on. Others seem 
to understand it and I don't know how to make it any clearer than it 
already is now. It certainly doesn't need a diff to understand it. But 
feel free to improve it yourself. Thanks.

-Gordon

---

## #71947 — Andrea Faulds — 2014-02-01T21:27:40+00:00

URL: https://externals.io/message/71886#71947 · In reply to: #71936

> Because it's different from already existing syntax (Code exists in
> the wild using HHVM's version of the syntax -
> https://wiki.php.net/rfc/constructor-promotion ).  I'm not sure which
> part you're confused about.

HHVM might already have it, yes, but PHP should strive for nicer and 
more obvious syntax choices. The PHP syntax is more obvious in what it does.

-- 
Andrea Faulds
http://ajf.me/

---

## #71951 — Chris Wright — 2014-02-01T22:55:08+00:00

URL: https://externals.io/message/71886#71951 · In reply to: #71936

Sara


> 
> > […]
> Because it's different from already existing syntax (Code exists in
> the wild using HHVM's version of the syntax -
> https://wiki.php.net/rfc/constructor-promotion ).  I'm not sure which
> part you're confused about.

It seems to me that there is no direct conflict here, the two are not
fundamentally incompatible and could quite comfortably co-exist in
HHVM (which is I guess the issue here - you want to ensure that HHVM
can run pure PHP - since there is already a lot of syntax in HHVM that
cannot make the transition the other way).

By contrast, the HHVM syntax *does* conflict with the recent extended
keyword support RFC [1], and as a passive observer to the discussion I
gauged a fairly positive reaction to this conceptually, the reason it
was rejected was largely because the implementation was not up to
standard - maybe I misread this but still, I don't recall this
conflict being brought up at the time. The HHVM syntax would also make
any future implementation of something like the recent property
accessors RFC [2] difficult to mix in.

I love some of things you guys have done with HHVM, but I don't like
the idea of the HHVM implementation of something blocking an alternate
route to the same goal suggested for PHP (especially when there is no
direct conflict) - otherwise we may as well just throw PHP development
out of the window and let the HHVM team decide where we go.

I realise I've made barely anything in the way of material
contributions to PHP, but even looking at it strictly from the point
of view of a user, I know I'm not alone in wanting PHP to do what PHP
does, and not necessarily what HHVM does (but if they coincide, so
much the better).

[1] https://wiki.php.net/rfc/keywords_as_identifiers
[2] https://wiki.php.net/rfc/propertygetsetsyntax-v1.2

Thanks, Chris

---

## #71953 — Gordon Oheim — 2014-02-01T23:39:39+00:00

URL: https://externals.io/message/71886#71953 · In reply to: #71936

> 
> > […]
> Because it's different from already existing syntax (Code exists in
> the wild using HHVM's version of the syntax -
> https://wiki.php.net/rfc/constructor-promotion ).  I'm not sure which
> part you're confused about.
>
> -Sara
>
I wasn't sure whether you meant that or some conflicts with core PHP 
syntax. Thanks for clarifying.

As much as I am looking forward to see HHVM mature, I don't think just 
because something is in HHVM already, it should have more weight when it 
comes to RFCs. It would effectively give FB control over what gets into 
PHP this way, simply because you are not community bound in what you add 
to HHVM. But I guess that's a topic for a wholly different debate.

A more immediate reason might be that the Ctor Promotion (CP) does more 
than just Automatic Property Initialization (API). It also does property 
declaration. That is entirely missing from the API RFC and makes the 
latter much less of a change than CP. It has virtually no impact on 
future features.

Personally, I don't like CP's declaration aspect, because it forces me 
to divide property declaration. Ctor injectable properties need to be 
declared in the ctor signature, while any others need to be declared in 
the class body (correct me if I am wrong please). I find that less 
readable and somewhat confusing.

I can see another issue in CP RFC #9: "Properties promoted in this 
fashion would not have their own DocBlock". How would that work then for 
frameworks using annotations, like Doctrine or Flow3? Again, this is not 
an issue when just using Automatic Property Initialization.

Don't get me wrong though. I think CP is an interesting proposal. But 
the consequences of also declaring properties makes the whole thing much 
more critical and it requires more thought to consider it for an addition.

-Gordon

---

## #71955 — pajousek@gmail.com — 2014-02-02T00:07:11+00:00

URL: https://externals.io/message/71886#71955 · In reply to: #71951

> Sara
>
> 
> > […]
>
> It seems to me that there is no direct conflict here, the two are not
> fundamentally incompatible and could quite comfortably co-exist in
> HHVM (which is I guess the issue here - you want to ensure that HHVM
> can run pure PHP - since there is already a lot of syntax in HHVM that
> cannot make the transition the other way).
>
> By contrast, the HHVM syntax *does* conflict with the recent extended
> keyword support RFC [1], and as a passive observer to the discussion I
> gauged a fairly positive reaction to this conceptually, the reason it
> was rejected was largely because the implementation was not up to
> standard - maybe I misread this but still, I don't recall this
> conflict being brought up at the time. The HHVM syntax would also make
> any future implementation of something like the recent property
> accessors RFC [2] difficult to mix in.
>
> I love some of things you guys have done with HHVM, but I don't like
> the idea of the HHVM implementation of something blocking an alternate
> route to the same goal suggested for PHP (especially when there is no
> direct conflict) - otherwise we may as well just throw PHP development
> out of the window and let the HHVM team decide where we go.
>
> I realise I've made barely anything in the way of material
> contributions to PHP, but even looking at it strictly from the point
> of view of a user, I know I'm not alone in wanting PHP to do what PHP
> does, and not necessarily what HHVM does (but if they coincide, so
> much the better).
>
> [1] https://wiki.php.net/rfc/keywords_as_identifiers
> [2] https://wiki.php.net/rfc/propertygetsetsyntax-v1.2
>
> Thanks, Chris
>
> --
> 
> 
>

Hello,

First of all, I hope I'm doing this correctly, since this is my very first post
to this mailing list. :)

Just want to give my opinion on these two options as a userland developer and
to say why I think the constructor promotion is much less practical than
the automatic property initialization.

Personally, I use a lots of annotations in my projects, especially in
the classes
where I could use this new feature.
And that's what's great about the __construct($this->foo) syntax, it could
really help in some places and be pretty compatible with annotations and stuff.
And if one day something like the C# style properties got accepted
(wishful thinking),
it would be pretty compatibile with it as well.

On the other hand, the constructor promotion feels like it isn't compatible
with stuff like annotations at all, and that it would be unuseable in
most cases.
Basically if you would want to save those few lines in constructor,
you'd have to give
up on other features regarding properties. Which downright sucks and
makes it a IMHO useless feature.

Regards
Pavel Kouril

---

## #71958 — Sara Golemon — 2014-02-02T01:18:34+00:00

URL: https://externals.io/message/71886#71958 · In reply to: #71947

> 
> > […]
>
> HHVM might already have it, yes, but PHP should strive for nicer and more
> obvious syntax choices. The PHP syntax is more obvious in what it does.
>
Who said anything about blocking?  I just don't think the approaches
have been contrasted enough to be able to say we've done due
diligence.  Don't put words in my mouth.

As to the PHP syntax being more obvious, I don't buy that statement.
Not that I think HHVM's syntax is any more obvious, but there's
nothing about this RFC's syntax which is any better.

-Sara

---

## #71959 — Andrea Faulds — 2014-02-02T01:20:52+00:00

URL: https://externals.io/message/71886#71959 · In reply to: #71958

> Who said anything about blocking?  I just don't think the approaches
> have been contrasted enough to be able to say we've done due
> diligence.  Don't put words in my mouth.

I don't know who said anything about blocking, where does my email 
mention it?

-- 
Andrea Faulds
http://ajf.me/

---

## #71960 — Sara Golemon — 2014-02-02T01:29:45+00:00

URL: https://externals.io/message/71886#71960 · In reply to: #71951

> It seems to me that there is no direct conflict here, the two are not
> fundamentally incompatible and could quite comfortably co-exist in
> HHVM (which is I guess the issue here - you want to ensure that HHVM
> can run pure PHP - since there is already a lot of syntax in HHVM that
> cannot make the transition the other way).
>
Correction: I want PHP code to be runnable anywhere, regardless of
which platform it was written for.  It makes me sad that so few people
on this list seem to care about cross-compatibility.

> By contrast, the HHVM syntax *does* conflict with the recent extended
> keyword support RFC [1], and as a passive observer to the discussion I
> gauged a fairly positive reaction to this conceptually, the reason it
> was rejected was largely because the implementation was not up to
> standard - maybe I misread this but still, I don't recall this
> conflict being brought up at the time. The HHVM syntax would also make
> any future implementation of something like the recent property
> accessors RFC [2] difficult to mix in.
>
Thank you.  This is what I was asking for.  A reason that was
something more than "HHVM does it so we have to do it differently."

That said, I don't like the look of [1] as it blurs the line between
the lexer and the parser.
The conflict with [2] is a 100% legit argument though.

> I love some of things you guys have done with HHVM, but I don't like
> the idea of the HHVM implementation of something blocking an alternate
> route to the same goal suggested for PHP (especially when there is no
> direct conflict) - otherwise we may as well just throw PHP development
> out of the window and let the HHVM team decide where we go.
>
Again.  Don't put words in my mouth.  I never said anything about
blocking a PHP feature based on a conflict with HHVM.  Stop putting
words in my mouth. Stop it.

> I realise I've made barely anything in the way of material
> contributions to PHP, but even looking at it strictly from the point
> of view of a user, I know I'm not alone in wanting PHP to do what PHP
> does, and not necessarily what HHVM does (but if they coincide, so
> much the better).
>
"So much the better" is my point.  I've said repeatedly that "because
hhvm does it" is not enough reason for PHP to do it.  HOWEVER, it is
reason to try to steer the implementations closer together, not drive
them apart.

> [1] https://wiki.php.net/rfc/keywords_as_identifiers
> [2] https://wiki.php.net/rfc/propertygetsetsyntax-v1.2

---

## #71961 — Sara Golemon — 2014-02-02T01:32:23+00:00

URL: https://externals.io/message/71886#71961 · In reply to: #71959

> 
> > […]
>
> I don't know who said anything about blocking, where does my email mention
> it?
>
My bad, that was Gordon.  Just getting peeved at having my motivations
and intentions called into question for having the audacity to want to
keep our implementations consistent.  But hey, let's just all invent
random bits of syntax, who cares about the users, right?

-Sara

---

## #71962 — Benjamin Eberlei — 2014-02-02T02:06:24+00:00

URL: https://externals.io/message/71886#71962 · In reply to: #71961

Imho HHVMs syntax has the massive flaw that you cannot use docblocks on
those properties anymore, which is not the case with this RFC. All other
things equal, this is why this RFC should clearly be favored.

Also with typehints or - unlikely but possible - property-accesors the hhvm
syntax will become very verbose for the __construct line, wheras this RFC
can handle those cases without having to think about future compatibility.




> 
> > […]
> mention
> > […]
> My bad, that was Gordon.  Just getting peeved at having my motivations
> and intentions called into question for having the audacity to want to
> keep our implementations consistent.  But hey, let's just all invent
> random bits of syntax, who cares about the users, right?
>
> -Sara

---

## #71965 — Sara Golemon — 2014-02-02T02:46:00+00:00

URL: https://externals.io/message/71886#71965 · In reply to: #71962

> Imho HHVMs syntax has the massive flaw that you cannot use docblocks on
> those properties anymore, which is not the case with this RFC. All other
> things equal, this is why this RFC should clearly be favored.
>
> Also with typehints or - unlikely but possible - property-accesors the hhvm
> syntax will become very verbose for the __construct line, wheras this RFC
> can handle those cases without having to think about future compatibility.
>
Inclined to agree on the matter of getters/setters (though I regard
the docblock issue as trivially solvable, and the typehint/verbosity
issue as a non-issue).

I've opened a discussion in the hhvm.dev group to look into this from
that side, and removed my "No" vote for the time being. (I'm not sold
on a "Yes" vote, however, as I'm not sure this buys us enough in its
proposed form).

-Sara

---

Next page: https://externals.io/message/71886.md?page=2