Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:97737
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.51 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <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> <910A374A-8C98-4F60-918D-CF0012FB7518@gmail.com>
Date: Thu, 12 Jan 2017 22:52:25 +0100
Message-ID: <CADyq6sLavvidMf6i1RqwZ5U_ivHSA2a_2PpwoRayzVnW6JK22Q@mail.gmail.com>
To: Tim Bezhashvyly <tim.bezhashvyly@gmail.com>
Cc: PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=f403045f5580d067440545ecbca5
Subject: Re: [PHP-DEV] Explicit constructor call and polymorphic dispatch
From: ocramius@gmail.com (Marco Pivetta)

--f403045f5580d067440545ecbca5
Content-Type: text/plain; charset=UTF-8

Hey Tim,

On Thu, Jan 12, 2017 at 10:51 PM, Tim Bezhashvyly <tim.bezhashvyly@gmail.com
> wrote:

> 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:
> >
> > On 1/12/2017 10:13 PM, Marco Pivetta wrote:
> >> Hey Richard,
> >>
> >> 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.
> >>
> >> 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).
> >>
> >> 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.
> >>
> >> Marco Pivetta
> >>
> >
> > 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.
> >
> > 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.
> >
> > ```
> > <?php
> >
> > final class DbConnection {
> >
> >  private $dsn;
> >
> >  private $initializer;
> >
> >  public function __construct($dsn) {
> >    $this->dsn = $dsn;
> >    // socket stuff happens here, much like with PDO
> >  }
> >
> >  public static function lazyInstance($dsn) {
> >    $reflector = new ReflectionClass(self::class);
> >    $self      = $reflector->newInstanceWithoutConstructor();
> >    $new       = $reflector->getConstructor();
> >
> >    $self->initializer = function () use ($self, $new, $dsn) {
> >      $new->invoke($self, $dsn);
> >      $self->initializer = function () {};
> >    };
> >
> >    return $self;
> >  }
> >
> >  public function query($queryString) {
> >    $this->initializer->__invoke();
> >
> >    // irrelevant from here on
> >    return ['query' => $queryString, 'dsn' => $this->dsn];
> >  }
> >
> > }
> >
> > $instance = DbConnection::lazyInstance('mysql://something');
> >
> > var_dump($instance);
> >
> > var_dump($instance->query('SELECT * FROM foo'));
> > var_dump($instance->query('SELECT * FROM bar'));
> > ```
> >
> > 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.
> >>
> >
> > 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.
> >
> > On 1/12/2017 10:34 PM, Tim Bezhashvyly wrote:
> >> And what about polymorphic dispatch?
> >>
> >
> > I think you need to elaborate a bit more here to get some feedback.
> >
> > --
> > Richard "Fleshgrinder" Fussenegger
>
>
That's generally understood as "Method overloading". There were more
discussions about it in here recently: you might want to look them up.

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

--f403045f5580d067440545ecbca5--