Re: [VOTE] Automatic Property Initialization

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