[RFC][VOTE] Default parent constructors RFC

Hi Stas,

On Sun, Jan 11, 2015 at 9:34 AM, Stanislav Malyshev smalyshev@gmail.com
wrote:

I'd like to initiate a vote on this RFC:
https://wiki.php.net/rfc/default_ctor

TLDR: this RFC would make a call to parent::__construct() succeed (as in
"not produce a fatal error") even if the parent class does not define a
ctor. Same for __destruct and __clone. The motivation for it is in the
RFC and here:
https://php100.wordpress.com/2014/11/04/default-constructors/

I've chosen the simplest way of implementing it, as suggested by Dmitry,
in https://github.com/php/php-src/pull/990. There are other
alternatives, but I think the simpler the better.

Previous discussion is at: http://marc.info/?t=141630266000001&r=2&w=2

Nice RFC. It covers __clone(), __destruct() also.
This would be great for rapid prototyping.

Small comment to the patch.

• (strcasecmp(Z_STRVAL_P(function_name), ZEND_DESTRUCTOR_FUNC_NAME) == 0 ||
• strcasecmp(Z_STRVAL_P(function_name), ZEND_CONSTRUCTOR_FUNC_NAME) == 0 ||
• strcasecmp(Z_STRVAL_P(function_name), ZEND_CLONE_FUNC_NAME) == 0)) {

The comparison order would be better

• (strcasecmp(Z_STRVAL_P(function_name), ZEND_CONSTRUCTOR_FUNC_NAME) == 0 ||
• strcasecmp(Z_STRVAL_P(function_name), ZEND_CLONE_FUNC_NAME) == 0 ||
• strcasecmp(Z_STRVAL_P(function_name), ZEND_DESTRUCTOR_FUNC_NAME) == 0)) {

I suppose default constructor is used most, then clone, destructor. It
depends on a script, though.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

De : Stanislav Malyshev [mailto:smalyshev@gmail.com]

TLDR: this RFC would make a call to parent::__construct() succeed (as in
"not produce a fatal error") even if the parent class does not define a
ctor. Same for __destruct and __clone. The motivation for it is in the
RFC and here: https://php100.wordpress.com/2014/11/04/default-
constructors/

+1.

Considering implicit empty constructors and destructors is totally intuitive and should have been done a long time ago.

For __clone, no opinion as I never used it.

François

Le 11/01/2015 01:34, Stanislav Malyshev a écrit :

I'd like to initiate a vote on this RFC:
https://wiki.php.net/rfc/default_ctor

Hi,

After discussing this RFC with other people of AFUP, we would be +1 on
this, by a small margin.

On one side, being able to always call a parent constructor without
having to check if it exists could be useful, especially when the parent
class is in a library.
On the other hand, it feels like the current situation doesn't cause
problems that often; and if a constructor is added to a parent class, it
will likely expect specific parameters, which means child classes will
need to be updated anyway.

--
Pascal MARTIN, AFUP - French UG
http://php-internals.afup.org/

Hi all,

On Sun, Jan 11, 2015 at 9:34 AM, Stanislav Malyshev smalyshev@gmail.com
wrote:

I'd like to initiate a vote on this RFC:
https://wiki.php.net/rfc/default_ctor

TLDR: this RFC would make a call to parent::__construct() succeed (as in
"not produce a fatal error") even if the parent class does not define a
ctor. Same for __destruct and __clone. The motivation for it is in the
RFC and here:
https://php100.wordpress.com/2014/11/04/default-constructors/

I've chosen the simplest way of implementing it, as suggested by Dmitry,
in https://github.com/php/php-src/pull/990. There are other
alternatives, but I think the simpler the better.

Previous discussion is at: http://marc.info/?t=141630266000001&r=2&w=2

It seems -1 vote are increasing. Therefore, I would like to mention
benefits of this RFC again.

This RFC is great for rapid app development/prototyping. There are many
cases that base
class constructors calls are needed or not. This RFC allow us to just call
parent constructor,
then add implementation later if it is needed.

It makes code maintenance easier for production code also.

I can understand the reason why people vote -1 (non existent
method/function calls should
not be able to be called and raise), but benefits override. IMHO.

PHP is for easier/faster development, isn't it?

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net