Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:97736
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.66 as permitted sender)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
In-Reply-To: <ae8078b2-17c6-09d9-e74f-9a9269d85dcb@fleshgrinder.com>
Date: Thu, 12 Jan 2017 22:51:12 +0100
Cc: Marco Pivetta <ocramius@gmail.com>
Content-Transfer-Encoding: quoted-printable
Message-ID: <910A374A-8C98-4F60-918D-CF0012FB7518@gmail.com>
References: <0DE25BF8-D349-48EF-A83B-8837DD4AD1E0@gmail.com>
 <CADyq6sJojHOKQ_CJvKGuBC9XrSAkoxGyi52=QjgFHHhzW+KFow@mail.gmail.com>
 <f0a40a8d-7937-43fb-b709-3539804a90a2@fleshgrinder.com>
 <CADyq6s+fN+5L5w87xeMa_VX4=rPVZFutMq3dO8UACiki56YSiQ@mail.gmail.com>
 <ae8078b2-17c6-09d9-e74f-9a9269d85dcb@fleshgrinder.com>
To: internals@lists.php.net
Subject: Re: [PHP-DEV] Explicit constructor call and polymorphic dispatch
From: tim.bezhashvyly@gmail.com (Tim Bezhashvyly)

Hi Richard,

thank you for support with __construct. I absolutely agree that it =
breaks BC and fine to propose it just for PHP 8.

By polymorphic dispatch I mean a possibility to have the same method =
(including constructor) in multiple variations. E.g.:

class Price
{
    public function __construct(int $price)
    {
        ...
    }

    public function __construct(string $price)
    {
        ...
    }
}

Regards,
Tim

> On 12 Jan 2017, at 22:39, Fleshgrinder <php@fleshgrinder.com> wrote:
>=20
> On 1/12/2017 10:13 PM, Marco Pivetta wrote:
>> Hey Richard,
>>=20
>> I made an example where everything was in a single class, but most
>> scenarios involve a lazy-loading wrapper that has no knowledge of the
>> original class besides its constructor.
>>=20
>> I use this approach to generate proxy classes that are "safe" to use =
with
>> fluent interfaces, for example (because fluent interfaces are really =
a mess
>> to work with).
>>=20
>> The alternative (for me, specifically) is to copy the constructor AST =
into
>> a closure, then store the closure somewhere. Still, if that closure =
also
>> calls the private constructor, I have to do it recursively, and so on =
until
>> I just give up :-P Also, this assumes codegen. Large pieces of code =
will
>> need rewriting, whereas I don't see strong reasoning for dropping a =
feature
>> that, while weird, is actually useful.
>>=20
>> Marco Pivetta
>>=20
>=20
> That actually calls out for reflection and that's what it is good for.
> Even if explicit construct calls are to be forbidden, the reflection =
API
> is definitely a different story.
>=20
> That being said, your remarks definitely tell everyone that a change =
in
> this area -- if wanted -- is only possible in PHP 8 and has to be
> considered a breaking change.
>=20
> ```
> <?php
>=20
> final class DbConnection {
>=20
>  private $dsn;
>=20
>  private $initializer;
>=20
>  public function __construct($dsn) {
>    $this->dsn =3D $dsn;
>    // socket stuff happens here, much like with PDO
>  }
>=20
>  public static function lazyInstance($dsn) {
>    $reflector =3D new ReflectionClass(self::class);
>    $self      =3D $reflector->newInstanceWithoutConstructor();
>    $new       =3D $reflector->getConstructor();
>=20
>    $self->initializer =3D function () use ($self, $new, $dsn) {
>      $new->invoke($self, $dsn);
>      $self->initializer =3D function () {};
>    };
>=20
>    return $self;
>  }
>=20
>  public function query($queryString) {
>    $this->initializer->__invoke();
>=20
>    // irrelevant from here on
>    return ['query' =3D> $queryString, 'dsn' =3D> $this->dsn];
>  }
>=20
> }
>=20
> $instance =3D DbConnection::lazyInstance('mysql://something');
>=20
> var_dump($instance);
>=20
> var_dump($instance->query('SELECT * FROM foo'));
> var_dump($instance->query('SELECT * FROM bar'));
> ```
>=20
> On 1/12/2017 10:34 PM, Tim Bezhashvyly wrote:
>> the only reason for prohibiting explicit __construct calls is that it
>> makes PHP objects mutable and it's state unpredictable. Still would
>> like to give this RFC a try.
>>=20
>=20
> I completely share this concern with Tim. Of course reflection would
> still allow one to circumvent any limitations imposed by the normal
> runtime. But that's what reflection is for after all.
>=20
> On 1/12/2017 10:34 PM, Tim Bezhashvyly wrote:
>> And what about polymorphic dispatch?
>>=20
>=20
> I think you need to elaborate a bit more here to get some feedback.
>=20
> --=20
> Richard "Fleshgrinder" Fussenegger