Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:86733
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.171 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <1434543855.21120.37.camel@kuechenschabe>
References: <CAJ9+bg7DVNQx=+Cbny4NDttEfTtzRsY=ZLaqgX1=kDLhzOnFQA@mail.gmail.com>
	<1434543855.21120.37.camel@kuechenschabe>
Date: Wed, 17 Jun 2015 15:25:54 +0200
Message-ID: <CAOjCV8xaJVKe+0B8nYsh5yutaPCMYij+S+jBN+uY6Ch3YizmDQ@mail.gmail.com>
To: =?UTF-8?Q?Johannes_Schl=C3=BCter?= <johannes@schlueters.de>
Cc: Lorenzo Fontana <fontanalorenz@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a113bb0d8607d2e0518b6a14c
Subject: Re: [PHP-DEV] Initializer List
From: sbj.ml.read@gmail.com ("Sebastian B.-Hagensen")

--001a113bb0d8607d2e0518b6a14c
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,

the proposed syntax also clashes with the new return type hints. They don't
make sense on construct, but reusing the same syntax for two different
things should be avoided if possible.

Hack implements a related approach (without most of the c++ guarantees and
benefits as it is pure syntactic sugar). If php wants to have something
similar, it may be favorable to talk to them why they chose to implement it
the way they did.

http://docs.hhvm.com/manual/en/hack.constructorargumentpromotion.php

Regards,

Am 17.06.2015 14:25 schrieb "Johannes Schl=C3=BCter" <johannes@schlueters.d=
e>:
>
> On Wed, 2015-06-17 at 10:03 +0200, Lorenzo Fontana wrote:
> > - In C++ using initializer list is used over assignment also for
> > performance reasons but right now I can't say if this can be achieved i=
n
> > PHP or not.
> >
> > Initializer lists in C++:
> > http://en.cppreference.com/w/cpp/language/initializer_list
>
> Mind that C++ doesn't do this to make code "nice" or "short" or whatever
> in that area but primarily due to need of control. Not having
> initializer lists means that object members in C++ have to be default
> constructible. Given C++ code like this
>
>    struct C {
>      SomeType a;
>      C(const SomeType& a) {
>        this->a =3D a;
>      }
>    }
>
> first calls the default constructor SomeType::SomeType() for a and then
> the assignment constructor (SomeType::operator=3D(const SomeType&) or
> similar)
>
> Another reason why C++ needs this ist const-correctness. In the example
> above it will fail if a is marked as const as the default constructor
> will initialize and assignment on const objects isn't valid.
>
> In PHP however the default constructor equivalent is setting the type to
> NULL which is (almost) for free while allocating the variable. Thus the
> need isn't there.
>
> You also write
>
> > public function __construct() : host("127.0.0.1") {};
>
> as example. But that ignores PHP's way to define default values:
>
> class Foo {
>     private $host =3D "127.0.0.1";
> }
>
> would be the PHP version to what you propose. At the same time I am
> confussed, by using a literal string there I assume you want to allow
> expressions there, but in other examples, like
>
> > public function __construct($name, $surname, $age) : name(name),
> >    surname(surname), age(age) {};
>
> you are not handling expressions (unless the constructor arguments are
> being ignored and properties are being initialized using the global
> constants name, surname and age, which I assume you didn't intend)
>
> You are also not discussing inheritance. Can I do
>
> class Base { /* .... */ }
> class Extended extends Base {
>     public function __construct() : parent(42) {}
> }
>
> how does that relate to parent::__construct()?
>
>
> In summary:
> I consider this syntactic sugar which in my opinion doesn't increase
> readability and in other languages solves an issue PHP doesn't have.
>
> johannes
>

--001a113bb0d8607d2e0518b6a14c--