Explicit constructor call and polymorphic dispatch

Am 12.01.2017 um 08:11 schrieb Tim Bezhashvyly:

Disallow explicit call of __construct method

I am baffled that this (still) works:

$ cat /tmp/t.php
<?php
class C
{
public function __construct()
{
print METHOD . PHP_EOL;
}
}

$o = new C;
$o->__construct();

$ php /tmp/t.php
C::__construct
C::__construct

$ php --version
PHP 7.1.0 (cli) (built: Dec 1 2016 07:39:00) ( NTS )
Copyright (c) 1997-2016 The PHP Group
Zend Engine v3.1.0-dev, Copyright (c) 1998-2016 Zend Technologies

I am in favor of an RFC to disallow explicit invocation of interceptor
methods such as __construct().

Can we do this in PHP 7.2 or does this have to wait for PHP 8?

https://github.com/php/php-langspec/blob/master/spec/14-classes.md#constructors

Constructors are called by object-creation-expression and from within
other (derived class) constructors.

This suggests that creation is possible via the new keyword only and
not via explicit calls to __construct. Hence, it could be categorized
as unspecified and dropped in 7.2.

However, there are other oddities that probably should be addressed too
in the context of constructors which are actually defined and thus can
only be removed in PHP 8.

A constructor can return a result, by value or byRef.

A constructor should not call its base-class constructor more than
once.

<?php
// test.php

class A {

  function __construct() {
    echo __CLASS__ , "\n";
  }

}

class B extends A {

  function __construct() {
    parent::__construct();
    echo __CLASS__ , "\n";
    parent::__construct();

    return "PHP\n";
  }

}

$b = new B;
echo $b->__construct();

$ php test.php
A
B
A
A
B
A
PHP

Note that both PHP and HHVM implement this correctly:

https://3v4l.org/DFGCa

--
Richard "Fleshgrinder" Fussenegger

I am baffled that this (still) works:

__clone was special cased in 5.x, but special case was removed in 7.0
means that previously you couldn't do publicly $obj->__clone(); now you can
and, yes, it's as dangerous as it looks
however, the special case was removed for a reason that i'm sure is a good
one, and i'm certain the same good reason is also valid for __construct

the only reason for prohibiting explicit __construct calls is that it makes

PHP objects mutable

then don't call it explicitly, exactly like you wouldn't use reflection to
call private methods

Heya,

While I agree that it is weird to be able to call constructors more than
once, this is generally used for:

• lazy loading
• resource reset

Specifically, what is going on is something like following:<?php

final class DbConnection
{
private $dsn;
private $initializer;
public function __construct(string $dsn)
{
$this->dsn = $dsn;
// socket stuff happens here, much like with PDO
}

public function query(string $queryString) : array
{
    ($this->initializer)();
    // irrelevant from here on
    return ['query' => $queryString, 'dsn' => $this->dsn];
}

public static function lazyInstance(string $dsn) : self
{
    $instance = (new

ReflectionClass(self::class))->newInstanceWithoutConstructor();
$instance->initializer = function () use ($dsn, $instance) {
$instance->__construct($dsn);
$instance->initializer = function () {
};
};
return $instance;
}
}

$instance = DbConnection::lazyInstance('mysql://something');

var_dump($instance);

var_dump($instance->query('SELECT * FROM foo'));
var_dump($instance->query('SELECT * FROM bar'));

Here's an example of it at work: https://3v4l.org/Y0eoL

The pattern is simple:

• intercept constructor call
• capture constructor parameters
• instantiate without constructor
• defer constructor call for later

The same can be used in a myriad of different ways, but this is a legit
use-cases that generally don't involve coding everything into the same
class (and I generally advise against doing that anyway).

Therefore I don't see a reason to drop manual constructor calls, unless
there is a strong necessity to get rid of 'em.

Marco Pivetta

Very creative but why not the following?

<?php

final class DbConnection {

  private $dsn;

  private $initialized = false;

  public function __construct($dsn) {
    $this->dsn = $dsn;
  }

  private function init() {
    $this->initialized = true;

    echo $this->dsn , "\n";
  }

  public function query($queryString) {
    // this is actually cheaper than calling the closure
    $this->initialized || $this->init();

    return ['query' => $queryString, 'dsn' => $this->dsn];
  }

}

$db_conn = new DbConnection('mysql://something');

var_dump(
  $db_conn,
  $db_conn->query('SELECT * FROM foo'),
  $db_conn->query('SELECT * FROM bar')
);

https://3v4l.org/PaqqZ

Works equally well in PHP and HHVM and achieves your goal without using
undocumented side effects and reflection.

Adding the ability of a non-lazy and lazy construction is easily added
too if desired.

--
Richard "Fleshgrinder" Fussenegger

Hi Marco,

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.

And what about polymorphic dispatch?

Regards,
Tim

Heya,

While I agree that it is weird to be able to call constructors more than once, this is generally used for:

• lazy loading
• resource reset

Specifically, what is going on is something like following:<?php

final class DbConnection
{
private $dsn;
private $initializer;
public function __construct(string $dsn)
{
$this->dsn = $dsn;
// socket stuff happens here, much like with PDO
}

public function query(string $queryString) : array
{
    ($this->initializer)();
    // irrelevant from here on
    return ['query' => $queryString, 'dsn' => $this->dsn];
}

public static function lazyInstance(string $dsn) : self
{
    $instance = (new ReflectionClass(self::class))->newInstanceWithoutConstructor();
    $instance->initializer = function () use ($dsn, $instance) {
        $instance->__construct($dsn);
        $instance->initializer = function () {
        };
    };
    return $instance;
}

}

$instance = DbConnection::lazyInstance('mysql://something');

var_dump($instance);

var_dump($instance->query('SELECT * FROM foo'));
var_dump($instance->query('SELECT * FROM bar'));

Here's an example of it at work: https://3v4l.org/Y0eoL https://3v4l.org/Y0eoL

The pattern is simple:

• intercept constructor call
• capture constructor parameters
• instantiate without constructor
• defer constructor call for later

The same can be used in a myriad of different ways, but this is a legit use-cases that generally don't involve coding everything into the same class (and I generally advise against doing that anyway).

Therefore I don't see a reason to drop manual constructor calls, unless there is a strong necessity to get rid of 'em.

Marco Pivetta

http://twitter.com/Ocramius http://twitter.com/Ocramius

http://ocramius.github.com/ http://ocramius.github.com/

Dear internals,

I would like to propose 2 RFCs:

• Disallow explicit call of __construct method
• Polymorphic dispatch

I'm sure I'm not the first who came with those 2 ideas so in case those were already proposed and rejected just let me know.

Otherwise please bless me with mana which will allow me to submit them.

Regards,
Tim

<http://www.php.net/unsub.php