Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:68430
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.179 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CE27EF9C.9917%seanc@fb.com>
References: <CE27EF9C.9917%seanc@fb.com>
Date: Thu, 8 Aug 2013 09:34:34 +0100
Message-ID: <CAPwsocFTxhuoLazpWC8Pt-r7H7vb=7a3G3=L19npQ6GD4CafqA@mail.gmail.com>
To: Sean Cannella <seanc@fb.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=f46d044402301f8f4504e36b87e8
Subject: Re: [PHP-DEV] RFC: constructor argument promotion
From: leight@gmail.com (Leigh)

--f46d044402301f8f4504e36b87e8
Content-Type: text/plain; charset=ISO-8859-1

On 7 August 2013 20:47, Sean Cannella <seanc@fb.com> wrote:

> https://wiki.php.net/rfc/constructor-promotion
>
> What do you all think?
>

I'm not sure what problem this is really trying to solve, the boilerplate
code you mention is very explicit and it is very clear to the reader what
is being done. Each property documented with its type, purpose and
visibility in a common place for easy reference (at the top of the class).
Each property that takes a value from the constructor assigned in the
constructor. Very clear.

To me this seems to be adding unnecessary magic and extra rules to remember
(the contrived case you mention at the bottom of the RFC for example would
actually be incredibly common) at the expense of readability and code
clarity.

--f46d044402301f8f4504e36b87e8--