Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91415
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.175 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CA+kxMuTHbsYAXe+J+jrFz+ZeguacEyUxCUpFJE8jMee_5+u_5g@mail.gmail.com>
References: <CA+kxMuTHbsYAXe+J+jrFz+ZeguacEyUxCUpFJE8jMee_5+u_5g@mail.gmail.com>
Date: Thu, 25 Feb 2016 13:20:11 -0500
Message-ID: <CADyq6sJCtY7oBxrFt+3YVrfz=gdRkgRmbk4y3ytgzHmRVWbUAA@mail.gmail.com>
To: Dan Ackroyd <danack@basereality.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7b3441dadb0987052c9c3c54
Subject: Re: [PHP-DEV] [RFC] Callable constructors
From: ocramius@gmail.com (Marco Pivetta)

--047d7b3441dadb0987052c9c3c54
Content-Type: text/plain; charset=UTF-8

Just adding to the use-cases: I really could've needed this the other day:


$records = array_map([MyRecord::class, '__construct'],
$db->someQuery()->fetchAll());

I used a named constructor instead, but this results with more internal
method calls:

$records = array_map([MyRecord::class, 'fromResultSetRow'],
$db->someQuery()->fetchAll());

So yeah, I see some clear advantages in making constructors (static by
design) available statically.


Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

On 25 February 2016 at 11:44, Dan Ackroyd <danack@basereality.com> wrote:

> Hello internals,
>
> I've written a small RFC to make it possible to call constructors of
> objects as a callable, rather than only being able to call them
> through the 'new' language construct.
>
> https://wiki.php.net/rfc/callableconstructors
>
> After gathering informal feedback for the RFC, one person said that
> they felt it needed more of an emphasis on why it should be
> implemented. I wanted to keep the actual RFC short, in the hope that
> more people would read it in it's entirety, and also wanted to leave
> library specific code out of the RFC. So, as an addendum to the RFC
> text:
>
> I use the Auryn* DIC library. What I've wanted to do, and should be
> able to do in my opinion, is this:
>
> $injector->delegate('FooInterface', 'FooImplementation::__construct');
>
> Which tells the injector "Whenever something requests an object that
> implements FooInterface as a dependency, just execute the
> FooImplementation constructor to make that object".
>
> If constructors had always been callable in PHP, this would be a
> standard thing to do and not controversial imo. It's only due to
> reasons lost in the mists of time, that object instantiation can only
> be invoked via 'new' that it's not possible currently, and so needs an
> RFC to change.
>
> As for the 'BC break' - I would be interested in hearing if anyone
> actually (admits to) having any code that would be affected by it.
>
> I think possibly the best way to manage this BC break, would be to
> make call_user_function($fn) behave the same as $fn(), when $fn =
> 'Foo::__construct' in a 7.0.x release, before adding the new
> functionality in 7.1.0. That would allow people to upgrade to a
> version where the changed behaviour breaks entirely, and so they can
> fix their code to use the correct calling semantics, before adding the
> new functionality in a later version. That give a clear way for people
> to detect problems, rather than it being a subtle change which is hard
> to detect. However I remain open to ideas on how to manage it better.
>
> cheers
> Dan
>
>
> * https://github.com/rdlowrey/auryn
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--047d7b3441dadb0987052c9c3c54--