Just adding to the use-cases: I really could've needed this the other day:

$records = array_map([MyRecord::class, '__construct'],

I used a named constructor instead, but this results with more internal
method calls:

$records = array_map([MyRecord::class, 'fromResultSetRow'],

So yeah, I see some clear advantages in making constructors (static by
design) available statically.

Marco Pivetta


On 25 February 2016 at 11:44, Dan Ackroyd 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.


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

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.


* https://github.com/rdlowrey/auryn

PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 5 of 24 | next ›
Discussion Overview
groupphp-internals @
postedFeb 25, '16 at 4:44p
activeMar 2, '16 at 6:19a



site design / logo © 2019 Grokbase