On Sat, Feb 1, 2014 at 11:55 PM, Chris Wright <[email protected]> wrote:
> Sara
>
> On 1 February 2014 19:53, Sara Golemon <[email protected]> wrote:
>> On Sat, Feb 1, 2014 at 11:43 AM, Gordon Oheim <[email protected]> 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