Hi,
I've opened the voting for 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
Hi,
I've opened the voting for 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
On Fri, Jan 31, 2014 at 10:30 PM, Johannes Schlüter
johannes@schlueters.de wrote:
Hi,
I've opened the voting for 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
On Fri, Jan 31, 2014 at 10:30 PM, Johannes Schlüter
johannes@schlueters.dewrote:
Hi,
I've opened the voting for 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,
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
Hi!
I've opened the voting for 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
Hi!
I've opened the voting for 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
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
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
I've opened the voting for 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
I've opened the voting for 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
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
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/
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
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/
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
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.
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
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
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
--
And how do you think the docblock issue could be trivially solvable?
Not from implementation POV,
but from syntactic POV?
Because I really don't want to write something like this:
/**
- @prop string $email @ORM\Column(type="string", unique=true)
@Assert\NotEmpty @Assert\Email - @prop string $username @ORM\Column(type="string", unique=true)
@Assert\NotEmpty
*/
public function __construct(private $email, private $username) { }
Sure, it saves tons of lines of code from the classic docblock over
class field approach, but it is not as easily
readable. One docblock per line seems infinitely better to me.
Also I'm not sure if it's OK to "reveal" internal class implementation
via docblock and constructor parameters.
Sara Golemon 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.
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).
Having 10+ years of legacy code which is built on a base of previous PHP4 code,
docblock is central to my own work practices. PHPEclipse simply picks up these
and provides annotation from them but is still a little behind on the 'newer'
changes which are now causing problems with third party libraries. I did have a
look at HHVM and failed because of the legacy code, but that was a little while
ago and I've not reviewed it recently. However I'm sure that there is probably
as much work moving the code to HHVM as there is remaining still to move it
forward toPHP5.5. It is all these little incremental changes which unless one
spends time actually clearing things each version update, eventually catch up to
the point where even PHP will not run code, let alone being cross compatible
with things like HHVM?
Making even simple PHP code runnable everywhere is a little of a pipe dream at
the moment. Even if you know how to configure the ini file to enable legacy code
to run, you then have to find the correct versions of third party libraries to
run with it.
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
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
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
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
Just that I never accused you of any of these things. I usually don't
even comment on other RFCs. I apologize again if it's coming across any
different (although it annoys me that I have to say that for the third
time now). So all I can ask from you is to take it as I tell you now:
it's not personal. It's not my intention to question your commitment
or blaming you of sabotaging PHP or whatever you think I wrote there.
Because I didn't. I have no interest in drama. It doesn't even have
anything to do with what is or isn't in HHVM, really. I told you what I
am concerned about and why I prefer my proposal over Ctor Promotion.
Believe it or not, but there is no hidden agenda or politics. I don't
have time for that.
-Gordon
Just that I never accused you of any of these things. I usually don't even
comment on other RFCs. I apologize again if it's coming across any different
(although it annoys me that I have to say that for the third time now). So
all I can ask from you is to take it as I tell you now: it's not personal.
It's not my intention to question your commitment or blaming you of
sabotaging PHP or whatever you think I wrote there. Because I didn't. I have
no interest in drama. It doesn't even have anything to do with what is or
isn't in HHVM, really. I told you what I am concerned about and why I prefer
my proposal over Ctor Promotion. Believe it or not, but there is no hidden
agenda or politics. I don't have time for that.
I don't doubt that we're both tired of repeating ourselves.
I did hear your concerns and why you prefer your proposal. As I said,
I may even agree with you about your syntax being better in terms of
accomplishing the stated goal. I haven't committed to a "yes" vote at
this point because I'm not convinced it's needed. Within the scope of
your syntax, it saves a single line per property at the cost of making
the prototype longer. To me, that's not actually enough to justify
it, especially if it means diverging the syntax trees.
That's the sum total of my objection. It's not an attempt to block the feature.
-Sara
Just that I never accused you of any of these things. I usually don't even
comment on other RFCs. I apologize again if it's coming across any different
(although it annoys me that I have to say that for the third time now). So
all I can ask from you is to take it as I tell you now: it's not personal.
It's not my intention to question your commitment or blaming you of
sabotaging PHP or whatever you think I wrote there. Because I didn't. I have
no interest in drama. It doesn't even have anything to do with what is or
isn't in HHVM, really. I told you what I am concerned about and why I prefer
my proposal over Ctor Promotion. Believe it or not, but there is no hidden
agenda or politics. I don't have time for that.I don't doubt that we're both tired of repeating ourselves.
I did hear your concerns and why you prefer your proposal. As I said,
I may even agree with you about your syntax being better in terms of
accomplishing the stated goal. I haven't committed to a "yes" vote at
this point because I'm not convinced it's needed. Within the scope of
your syntax, it saves a single line per property at the cost of making
the prototype longer. To me, that's not actually enough to justify
it, especially if it means diverging the syntax trees.That's the sum total of my objection. It's not an attempt to block the feature.
-Sara
Fair enough.
-Gordon
Sara
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
Sara
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.2Thanks, 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
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
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