[RFC] Default constructors View as Markdown

Hi!

mean we should add this, though. Because this RFC means you can just
blindly call the constructor, whether or not it exists, and expect it

Yes, that's exactly what it means and it's good, not bad - new() has
been doing that for years and nobody complained.

to work. And that is bad: If you don’t know how the parent class
works, you really shouldn’t be extending it. -- Andrea Faulds

That sounds just wrong - information hiding is a basic premise of OO,
and to extend the object you shouldn't have to know the intimate details
of its implementation. In fact, in many cases you can't - such as with
internal classes. That's why we have problems with class initilization
for extending internal classes - because people are trained "you can't
just call the parent ctor, you need to verify things thoroughly first".
And that'd exactly wrong. If you know you can create an object without
parameters - new Foo() - then you should be able to extend it and call
parent::__construct() - which is supposed to do exactly the same.
Unfortunately, in PHP - unlike pretty much any other OO language - you
can not.

Hi!

Does it really make sense for PHP? What if that parent class 'Animal'
from your example introduces a constructor that accepts, say, both
$owner and $what as mandatory arguments? parent::__construct()

Then you need to rewrite all descendant classes anyway, this would be
API change, not an API-preserving refactoring. Essentially, you take the
Animal class and replace it with entirely different class with different
requirements. You'll have to rewrite all the code that constructs Animal
objects. This obviously is not the scenario I'm talking about (and of
course nowhere near recommended practice for any maintainable code).

call in a descendant will appear broken (unintentionally, I suppose),
won't it? That'll work in Java just fine, though.

In Java, you can not do that - if your ctor requires 2 arguments, you'd
have to give it 2 arguments. If you still have the default ctor, that'd
be fine, and so it will be in PHP - but in PHP you can not have two ctor
functions, so in PHP you do things differently, we use optional
arguments instead of using two functions. The meaning is the same though

• if you're able to call new Foo(), you should be able to call
  parent::__construct() (or super() in Java case) on Foo. Except in Java
  it works and in PHP it doesn't. That's what I want to fix.

Does it really make sense for PHP? What if that parent class
'Animal' from your example introduces a constructor that accepts, say,
both $owner and $what as mandatory arguments?
parent::__construct() call in a descendant will appear broken
(unintentionally, I suppose), won't it?

If you introduce a mandatory parameter to any function, method, or
constructor, existing calls to that function, method, or constructor
will be broken.

A class with no defined constructor already behaves as if its
constructor had no arguments when using "new", so introducing a
constructor with mandatory arguments is already a breaking change.

--
Rowan Collins
[IMSoP]

Personally, I would much prefer the backwards compatibility break to happen. It is frankly quite bizarre, and not at all useful, that the following two pieces of code behave differently:

class Foo {}
new Foo( print('hello') );
// silent

vs

class Foo { function __construct() {} }
new Foo( print('hello') );
// says "hello"

(Incidentally, HHVM doesn't have this "optimisation", and says "hello" in both cases: http://3v4l.org/ZDXs1)

If I came upon this without knowing more, I would assume it was a bug in PHP, and any code relying on it was in need of fixing ASAP.

In fact, it is a bug: https://bugs.php.net/bug.php?id=67829

--
Andrea Faulds
http://ajf.me/

Andrea Faulds wrote on 18/11/2014 13:11:

On Tue, Nov 18, 2014 at 1:35 PM, Ivan Enderlin @ Hoa <
ivan.enderlin@hoa-project.net> wrote:

Hello :-),

Is it not simpler to create a super-object whom all objects are children
of? Something similar to the Java Object?
yeah, this was also a suggested alternative when discussing this problem
previously(see the link in my previous mail).
I'd certainly like it if everything descended from some class (Object? StdClass?), but I don't like the idea of an empty construct. As Anthony pointed out last time, you can't do inheritance and simultaneously treat the parent class as a black box.

The thing is that without any way of monkey-patching the default object,
there isn't much difference between "all objects have a default
constructor" and "all objects have a default parent", other than "$foo
instanceOf Object" always returning true.

Regards,

Rowan Collins
[IMSoP]

thanks Stas. I'll think on next week.

Dmitry.

On Fri, Nov 21, 2014 at 6:59 AM, Stanislav Malyshev smalyshev@gmail.com
wrote:

Hi!

Additional check for ZEND_NULL_FUNCTION in DO_FCALL may be expensive.
I think it must be better to use special predefined function (see
"zend_pass_function" usage in zend_vm_def.h).

I've made a different implementation here:

https://github.com/smalyshev/php-src/compare/php:master...smalyshev:default_ctor_func?expand=1

which uses zend_pass_function but I had to make it static since
otherwise it's increase refcount for object and it doesn't seem like it
decrements back. So I'm not sure if it's right, what do you think?

--
Stas Malyshev
smalyshev@gmail.com