Everything

php

[VOTE] Automatic Property Initialization

php.internals

Gordon Oheim

12 years ago

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

Johannes Schlueter

12 years ago

On Fri, 2014-01-31 at 20:18 +0100, gooh wrote:

> 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

Pascal Chevrel

12 years ago

Le 31/01/2014 22:30, Johannes Schlüter a écrit :

> On Fri, 2014-01-31 at 20:18 +0100, gooh wrote:
>> 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
>
>

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

Unnamed Person

12 years ago

On 2014-01-31 14:41, Pascal Chevrel wrote:

> Le 31/01/2014 22:30, Johannes Schlüter a écrit :
>> On Fri, 2014-01-31 at 20:18 +0100, gooh wrote:
>>> 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
>>
>>
>
> 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);

Johannes Schlueter

12 years ago

Hi Pascal,

On Fri, 2014-01-31 at 23:41 +0100, Pascal Chevrel wrote:

> 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

Dan Ackroyd

12 years ago

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:

Johannes Schlueter

12 years ago

On Fri, 2014-01-31 at 23:48 +0000, Dan Ackroyd wrote:

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

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

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

Joe Watkins

12 years ago

Morning internalz,

Some clarity ...

> Johannes:
> 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;

Assuming you meant to declare Base::__construct abstract:

L1946 zend_compile.c:

> zend_error(E_COMPILE_ERROR, "Automatic property initialization can

not be used in an abstract method");

> leading to probably unexpected results ... also
>     class C { public function m($foo->prop){}}

L1933 zend_compile.c:

> zend_error(E_COMPILE_ERROR, "Property name can only be prefixed by

$this->");

Having reviewed the discussion, and played with the patch, I see no
genuine objection.

Cheers
Joe

Pierre Joye

12 years ago

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

> On Fri, 2014-01-31 at 20:18 +0100, gooh wrote:
>> 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.

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

Ferenc Kovacs

12 years ago

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

> On Fri, 2014-01-31 at 20:18 +0100, gooh wrote:
> > 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
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

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

Stas Malyshev

12 years ago

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

Joe Watkins

12 years ago

On 02/01/2014 09:04 AM, Stas Malyshev wrote:

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

> 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

Stas Malyshev

12 years ago

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

Gordon Oheim

12 years ago

On 01.02.2014 20:59, Stas Malyshev wrote:

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

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

Sara Golemon

12 years ago

On Fri, Jan 31, 2014 at 11:18 AM, gooh <gooh@php.net> wrote:

> 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

Gordon Oheim

12 years ago

On 01.02.2014 20:25, Sara Golemon wrote:

> On Fri, Jan 31, 2014 at 11:18 AM, gooh <gooh@php.net> wrote:
>> 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
>

How is it conflicting?

-Gordon

Sara Golemon

12 years ago

On Sat, Feb 1, 2014 at 11:43 AM, Gordon Oheim <gooh@php.net> wrote:

> On 01.02.2014 20:25, Sara Golemon wrote:
>> 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.
>>
> 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

Andrew Faulds

12 years ago

On 01/02/14 19:53, Sara Golemon wrote:

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

Sara Golemon

12 years ago

On Sat, Feb 1, 2014 at 1:27 PM, Andrea Faulds <ajf@ajf.me> wrote:

> On 01/02/14 19:53, Sara Golemon wrote:
>> 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.
>

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

Andrew Faulds

12 years ago

On 02/02/14 01:18, Sara Golemon wrote:

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

Sara Golemon

12 years ago

On Sat, Feb 1, 2014 at 5:20 PM, Andrea Faulds <ajf@ajf.me> wrote:

> On 02/02/14 01:18, Sara Golemon wrote:
>> 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?
>

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

Benjamin Eberlei

12 years ago

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.


On Sun, Feb 2, 2014 at 2:32 AM, Sara Golemon <pollita@php.net> wrote:

Sara Golemon

12 years ago

On Sat, Feb 1, 2014 at 6:06 PM, Benjamin Eberlei <kontakt@beberlei.de> wrote:

> 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

Gordon Oheim

12 years ago

On 02.02.2014 02:32, Sara Golemon wrote:

> On Sat, Feb 1, 2014 at 5:20 PM, Andrea Faulds <ajf@ajf.me> wrote:
>> On 02/02/14 01:18, Sara Golemon wrote:
>>> 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?
>>
> 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
>

Not sure where I said anything about blocking, but for the record: I
don't question your motivations or intentions. Not at all. Sorry, if it
came across that way. I appreciate all the hard work you put into HHVM
and PHP. I agree about consistent implementations, but I also think the
main driver here should be the community and not FB. Otherwise FB will
be able to dictate PHP's future once HHVM has reached critical mass. Has
nothing to do with you personally (or anyone else on your team). It's
just a concern I have and judging by some other responses, I am not
alone with that concern.

-Gordon

--
http://about.me/gooh

Sara Golemon

12 years ago

On Sun, Feb 2, 2014 at 12:27 AM, Gordon Oheim <gooh@php.net> wrote:

> Not sure where I said anything about blocking, but for the record: I don't
> question your motivations or intentions. Not at all. Sorry, if it came
> across that way. I appreciate all the hard work you put into HHVM and PHP. I
> agree about consistent implementations, but I also think the main driver
> here should be the community and not FB. Otherwise FB will be able to
> dictate PHP's future once HHVM has reached critical mass. Has nothing to do
> with you personally (or anyone else on your team). It's just a concern I
> have and judging by some other responses, I am not alone with that concern.
>

Right there is what I'm talking about.

You're making assertions about PHP being a community driven project
against a backdrop of evil mr corporation being antithetical to that
goal.  I am a member of this community as well, and when you call my
commitment into question just two sentences after apologizing for
"coming across that way", then it's not an apology and I return the
favor by calling your intentions into question.

Let me be clear: HHVM will never be able to dictate PHP's future.  PHP
is more than its engine.  PHP is the people who drive it forward, both
here on this list and around the community building tools and
frameworks and everything else.  If it does hit a critical mass, then
you know what will happen?  We'll take what we want from it (because
users are asking for it), and we'll leave what we don't.  That's not
HHVM bullying us into doing something, that's PHP growing in response
to community demand.

I know we're not always going to agree on how a feature should be
implemented (or even that it should).  The RFC process exists so that
we can collectively decide what's best for the language.  But you can
bet your ass I'll get pissed when it comes down to: "Let's go for a
different syntax... just because", or worse "because fuck hhvm".

I'm not saying that's entirely happening here, at least one good
argument for the proposed syntax has been put forth, but it's happened
on a number of rfcs recently and the tone is certainly coming across
from some posts on this one.  I don't appreciate this trend of
sabotaging PHP, then blaming me for "trying to block features" when I
ask for a discussion on consistency.  Because that is personal, even
if you claim it isn't.

-Sara

Chris Wright

12 years ago

Sara

On 1 February 2014 19:53, Sara Golemon <pollita@php.net> wrote:

> On Sat, Feb 1, 2014 at 11:43 AM, Gordon Oheim <gooh@php.net> wrote:
>> On 01.02.2014 20:25, Sara Golemon wrote:
>>> 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.
>>>
>> 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.

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

Pavel Kouřil

12 years ago

On Sat, Feb 1, 2014 at 11:55 PM, Chris Wright <daverandom@php.net> wrote:

> Sara
>
> On 1 February 2014 19:53, Sara Golemon <pollita@php.net> wrote:
>> On Sat, Feb 1, 2014 at 11:43 AM, Gordon Oheim <gooh@php.net> wrote:
>>> On 01.02.2014 20:25, Sara Golemon wrote:
>>>> 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.
>>>>
>>> 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.
>
> 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
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

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

Sara Golemon

12 years ago

On Sat, Feb 1, 2014 at 2:55 PM, Chris Wright <daverandom@php.net> wrote:

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

Gordon Oheim

12 years ago

On 01.02.2014 20:53, Sara Golemon wrote:

> On Sat, Feb 1, 2014 at 11:43 AM, Gordon Oheim <gooh@php.net> wrote:
>> On 01.02.2014 20:25, Sara Golemon wrote:
>>> 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.
>>>
>> 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
>

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