Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:72011 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 12544 invoked from network); 2 Feb 2014 18:06:48 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 2 Feb 2014 18:06:48 -0000 Authentication-Results: pb1.pair.com header.from=danack@basereality.com; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=danack@basereality.com; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain basereality.com from 209.85.160.171 cause and error) X-PHP-List-Original-Sender: danack@basereality.com X-Host-Fingerprint: 209.85.160.171 mail-yk0-f171.google.com Received: from [209.85.160.171] ([209.85.160.171:37417] helo=mail-yk0-f171.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 4C/51-30967-6398EE25 for ; Sun, 02 Feb 2014 13:06:48 -0500 Received: by mail-yk0-f171.google.com with SMTP id 142so34003811ykq.2 for ; Sun, 02 Feb 2014 10:06:44 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=MH/E8yLQ7b+u0IYya0tqY8TnnYRfe00GfNQO9sN8klA=; b=iDl6j9eEWgcn6B+J3O5bc/YCcJdRshgAz3PNZj3oM3FCXjzhy0PCcmRjHZ4sYhntNb SZrQhlWcenynQTXcC1l11B9CBgn3XOJ6wDpsG4xf3wIZi0D0UgUwqdvYqd6qY3t7C5JN cmH+xV5SXRNDrGONPsCI2kCyuMNuhdeA0+KA8bWrCdDUi0//hTWgVO5rVcN9w5qfKK8x 6LgiaDuRALv0tmCVLdzlnnvLGDqW3/e2OgM1RNRZX5nmLbjMNiVcPubIuP2OQ857iO63 oQJgtt4TdKeyWt3xbxkz7onbBwoVB1hOhkiQ8ssRGlOCFyY8wx+Vv2Qez2qrBZYDIr73 Dmvw== X-Gm-Message-State: ALoCoQmuSMo6A2I6RJhGtFN8xgwm7sN0NyMTk0TosP3kKS4XxOVtrnKlwn0PBuQFZq0IQ8okBRtv MIME-Version: 1.0 X-Received: by 10.236.201.77 with SMTP id a53mr14831yho.104.1391364404129; Sun, 02 Feb 2014 10:06:44 -0800 (PST) Received: by 10.170.57.137 with HTTP; Sun, 2 Feb 2014 10:06:44 -0800 (PST) X-Originating-IP: [78.149.15.108] In-Reply-To: References: Date: Sun, 2 Feb 2014 18:06:44 +0000 Message-ID: To: Sean Cannella Cc: "internals@lists.php.net" Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [PHP-DEV] RFC: constructor argument promotion From: danack@basereality.com (Dan Ackroyd) Hi, A little late to the game but here are some reasons why this RFC seems be a bad idea to implement. 1) It makes it easier to write subtle bugs. e.g. class A { function __construct(protected $foo1 = 'A1', private $foo2 = 'A2') { } //other methods that use $this->foo2 } class B extends A { function __construct(protected $foo1 = 'B1', private $foo2 = 'B2') { parent::__contruct(); } //other methods that use $this->foo2 } Class A and class B each have their own private copy of $foo2, but share the single instance of property $foo1. Which is quite surprising behaviour. 2) For my reading of the proposed RFC, I don't think it can safely be used for sub-classes. i.e. if you wrote this code in the new proposed syntax. class SQLConnection extends DBConnection {} class A { function __construct(protected DBConnection $dbConnection){} } class B extends A { function __construct(protected SQLConnection $dbConnection){} } That would be equivalent to writing this code in the current PHP syntax. class A { /** @var DBConnection */ protected $dbConnection; function __construct(DBConnection $dbConnection){} } class B extends A { /** @var SQLConnection */ protected $dbConnection; function __construct(SQLConnection $dbConnection){ $this->dbConnection = $dbConnection; } } But that's not what you would want. You don't want class B to redeclare the property with a different type. So either the RFC would have to implement some complex rules for typehinting, or people would have to avoid using this syntax in sub-classes. 3) It hinders future ability to make new features on properties, such as the RFC https://wiki.php.net/rfc/propertygetsetsyntax-alternative-typehinting-syntax Cramming the declarations of properties into the constructor make it almost impossible for any future RFC that wants to affect how properties are declared. 4) Makes code harder to read. Currently the comments for a property will be written directly above that property, so if you want to read the comment for a property in any decent IDE you can i) Click on the property ii) Move your eyes up one line, and you're reading the comment for the property. This RFC moves the comments further away and so you have to scan up lines of code to figure out where the properties comment is. Even if the other negative features of this RFC weren't present, making code harder to read and maintain defeats any gain from a bit less typing. 5) Breaks current ecosystem of annotations. People who use annotations for properties would have to rewrite their tools to support a new syntax. Although that is sometimes necessary, it is a negative point for this RFC. To summarise, to me this RFC seems to have lots of negative features. The RFC currently under vote (https://wiki.php.net/rfc/automatic_property_initialization#vote) doesn't save quite as much typing as this RFC would, but doesn't suffer from any of the above negative features and so seems far better to me. If people prefer this RFC it'd be nice if there was some suggestions of how to fix these issues. cheers Dan On Wed, Aug 7, 2013 at 8:47 PM, Sean Cannella wrote: > Everyone - > > Hi! Since this is my first post to this list, I'll introduce myself: > I'm an engineer who has been working on HipHop VM in New York for the last half year or so after a long time working at Microsoft on business software and services in multiple hemispheres. > > I wanted to get the PHP community's opinion on this feature. See the draft RFC and referenced implementation below: > > https://wiki.php.net/rfc/constructor-promotion > > What do you all think? > > Thanks, > Sean Cannella | Facebook Eng > If you are smart and persistent, you may find the truth. It is not always a reward.