Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:71955 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 96949 invoked from network); 2 Feb 2014 00:07:16 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 2 Feb 2014 00:07:16 -0000 Authentication-Results: pb1.pair.com header.from=pajousek@gmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=pajousek@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.42 as permitted sender) X-PHP-List-Original-Sender: pajousek@gmail.com X-Host-Fingerprint: 209.85.216.42 mail-qa0-f42.google.com Received: from [209.85.216.42] ([209.85.216.42:57958] helo=mail-qa0-f42.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 60/BB-30967-23C8DE25 for ; Sat, 01 Feb 2014 19:07:14 -0500 Received: by mail-qa0-f42.google.com with SMTP id k4so8447359qaq.29 for ; Sat, 01 Feb 2014 16:07:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Z5lW1/2WEutMx1bsEKQcyNUCKkvtHnDrnouPx59455g=; b=aBjxMfhAdDD2JlBMBV6axLLjik9alUlbtY17umLkQNrcbgnNRCL7A/reAmhsfRpb5q cvP6VvEdpT9DPy5kbLpHGIpX7/GvUJ7Y+6cRO1sQ0BmRXBP+0jYIqkeltbK6Yyju64O2 aHj9Nf6gs8zKsUtWDvyXZkoCBIzSzZBujt5pdsZ51YtGz8P+8MwzWDUSyaClcVRa39jL BpnJZzyEkf+Zx89svonYRq0dfk8Om7a5gD28FSceZVK6IuSpbfTehGGu8A+pTP9gGZUa nJhidlpmZBZNGe3+zMMUgyoSFf67cWraXA1CT7HB/XWWNfJSP9k+fB4FAX8NptMjADaa 5bSg== MIME-Version: 1.0 X-Received: by 10.224.127.131 with SMTP id g3mr44194729qas.98.1391299631861; Sat, 01 Feb 2014 16:07:11 -0800 (PST) Received: by 10.96.86.134 with HTTP; Sat, 1 Feb 2014 16:07:11 -0800 (PST) In-Reply-To: References: <98.E0.35265.E17FBE25@pb1.pair.com> Date: Sun, 2 Feb 2014 01:07:11 +0100 Message-ID: To: Chris Wright Cc: Sara Golemon , Gordon Oheim , PHP internals Content-Type: text/plain; charset=UTF-8 Subject: Re: [PHP-DEV] [VOTE] Automatic Property Initialization From: pajousek@gmail.com (=?UTF-8?Q?Pavel_Kou=C5=99il?=) On Sat, Feb 1, 2014 at 11:55 PM, Chris Wright wrote: > Sara > > On 1 February 2014 19:53, Sara Golemon wrote: >> On Sat, Feb 1, 2014 at 11:43 AM, Gordon Oheim 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