Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:97752
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.66 as permitted sender)
MIME-Version: 1.0
Sender: giovanni.g@gmail.com
In-Reply-To: <BC86F6B0-0B13-4DCA-9738-9019363953B2@heigl.org>
References: <0DE25BF8-D349-48EF-A83B-8837DD4AD1E0@gmail.com>
 <5efcc230-c67b-4439-cc82-b31eacbf36db@php.net> <CAOv67gsHZRBXugtknriqz4ofndsfaS2KBFjjMdahqKpCB8c+kA@mail.gmail.com>
 <7c8c8801-a849-6fd2-91e9-954030c55e83@fleshgrinder.com> <cc6bc980-29fd-2c6f-fc67-0de79c27409a@heigl.org>
 <2051639b-1b63-2e44-51b0-381caa54dfd0@fleshgrinder.com> <BC86F6B0-0B13-4DCA-9738-9019363953B2@heigl.org>
Date: Sat, 14 Jan 2017 15:58:18 +0100
Message-ID: <CAML1Pf7CobE=cf6MWi41oT+6vkg91fcvjwi0v937vpgDWVuvzw@mail.gmail.com>
To: Andreas Heigl <andreas@heigl.org>
Cc: internals@lists.php.net, Wes <netmo.php@gmail.com>, sebastian@php.net
Content-Type: multipart/alternative; boundary=001a114791004c1cb105460f2e4e
Subject: Re: [PHP-DEV] Explicit constructor call and polymorphic dispatch
From: giovanni@giacobbi.net (Giovanni Giacobbi)

--001a114791004c1cb105460f2e4e
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I'm surprised no one is raising a strong argument about the
"parent::__construct()" call, so I'll do it.

I never liked typing "parent::__construct()" to call parent's class
constructor, but now that this proposal is being discussed (and might even
be accepted) I would like to throw some more meat to the fire:

<?php
class C {
  function __construct($a) {
    print "C::__construct() a=3D$a\n";
  }
}
class D extends C {
  function __construct($a, $b) {
    parent::__construct($a, $b); // how it is now
    // parent($a);   // how i would like it
    print "D::__construct() a=3D$a b=3D$b\n";
  }
}
$d =3D new D(10, 20);

If you go for blocking explicit calls to __construct() (i'm personally in
favour of it), i hope you would change the syntax for its only legitimate
use which is calling the parent's constructor within a constructor, so how
about something like parent(...)?
It would be ugly to say "You are not supposed to explicit call
__construct() *ever*" and then "You know what, to initialize parent class
you need to call __construct()".

The construct method is called automagically when you instantiate the
class, I don't type something like $d =3D new D; $d->__construct(10, 20); s=
o
I don't see why I should type that method name inside my derived
constructor. I just need a special syntax to do so.

And while I'm at it (a bit offtopic but related to my previous argument)
how about *not* requiring __construct() to be defined in the parent class?
I.e. when you call parent::__construct() if there is NO constructor defined
in the parent class just do nothing instead of going fatal error. I
*always* wanted this feature, because when you do "new C;" it doesn't go
fatal error if there is no __construct() defined. I don't think this is
breaking covariance if you assume that every class defines an empty
__construct() with no argument. I mean, if you later add an explicit
constructor to the parent class it *must* be without arguments unless you
accept you might break something.

Thanks!


On 14 January 2017 at 13:15, Andreas Heigl <andreas@heigl.org> wrote:

>
>
> > Am 14.01.2017 um 11:26 schrieb Fleshgrinder <php@fleshgrinder.com>:
> >
> >> On 1/14/2017 11:20 AM, Andreas Heigl wrote:
> >> Do we as "makers of PHP" want to dictate the user what the "intended"
> >> behaviour of PHP is? Or are we treating the user as a responsible pers=
on
> >> that knows what to do and also not to do?
> >>
> >> Personally I'm in favour of the later. Let the user be able to call
> >> __construct whenever they like. It's a special method which is clearly
> >> visible by the two underscores at the start. So the users either know
> >> exactly what they are doing or they need to learn it.
> >>
> >> Translated to a different example this discussion is like: "Let's remo=
ve
> >> the handle from the window because someone might be able to open the
> >> window and jump out of it". The handle is there for a valid reason. An=
d
> >> as a window-maker I have no idea in what way it might be used. But I
> >> have to accept that there are people missusing it. But should I limit
> >> all those users with a valid use-case for it just to save some from
> >> missusing it? And if we start with that, where should we stop?
> >>
> >> Just my 0.02=E2=82=AC
> >>
> >> Cheers
> >>
> >> Andreas
> >>
> >
> > Yes, that is exactly the question. This needs to be voted on. Rust woul=
d
> > be an example that protects you and C/C++ would be examples that do not=
.
> > Both approaches are valid approaches.
> >
> > Note that the dictation will not always work, this is why e.g. Rust has
> > unsafe blocks. The corresponding thing in PHP imho would be reflection.
> > Hence, if someone has a special case:
> >
> > - Rust: use unsafe
> > - PHP: use reflection
> >
> > --
> > Richard "Fleshgrinder" Fussenegger
>
> IMHO it already IS safe.
>
> In PHP 4 the "constructor" was a method thad had the same name as the
> class. But now it is a class that has always the same name and is always
> preceded with two underscores. There is no way to "accidentaly" call that
> method. You have to explicitly call "__construct" to "break" things.
>
> If developers "want" to break something they will find a way. Protecting
> "__construct" will not stop them from doing so. But it will stop the rest
> of us do legitimate things.
>
> Cheers
>
> Andreas
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


--=20
Giovanni Giacobbi

--001a114791004c1cb105460f2e4e--