Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:97755
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain brzuchalski.com designates 188.165.245.118 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAML1Pf7CobE=cf6MWi41oT+6vkg91fcvjwi0v937vpgDWVuvzw@mail.gmail.com>
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>
 <CAML1Pf7CobE=cf6MWi41oT+6vkg91fcvjwi0v937vpgDWVuvzw@mail.gmail.com>
Date: Sat, 14 Jan 2017 19:10:19 +0100
Message-ID: <CABdc3WpENT=pArKbm9LJCFpJG1vx2AkHGrx-2Jw0qZu7sv1wEw@mail.gmail.com>
To: Giovanni Giacobbi <giovanni@giacobbi.net>
Cc: Andreas Heigl <andreas@heigl.org>, PHP Internals List <internals@lists.php.net>, 
	Wes <netmo.php@gmail.com>, sebastian@php.net
Content-Type: multipart/alternative; boundary=001a114bd27002a67b054611dd19
Subject: Re: [PHP-DEV] Explicit constructor call and polymorphic dispatch
From: michal@brzuchalski.com (=?UTF-8?Q?Micha=C5=82_Brzuchalski?=)

--001a114bd27002a67b054611dd19
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

2017-01-14 15:58 GMT+01:00 Giovanni Giacobbi <giovanni@giacobbi.net>:

> 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 eve=
n
> 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 ho=
w
> about something like parent(...)?
>

AFAIK parent is a speciual scope which help refers to variables and
functions in base classe
http://php.net/manual/kr/keyword.parent.php
So it looks like proposing your syntax could lead to huge BC break.
In other languages (eg. Java) there is special syntax quite similar with
`super($a, $b)` call.



> 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);=
 so
> 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 defin=
ed
> 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
> person
> > >> 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 clear=
ly
> > >> visible by the two underscores at the start. So the users either kno=
w
> > >> exactly what they are doing or they need to learn it.
> > >>
> > >> Translated to a different example this discussion is like: "Let's
> remove
> > >> 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.
> And
> > >> 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 limi=
t
> > >> 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
> would
> > > 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 h=
as
> > > unsafe blocks. The corresponding thing in PHP imho would be reflectio=
n.
> > > 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 alway=
s
> > preceded with two underscores. There is no way to "accidentaly" call th=
at
> > method. You have to explicitly call "__construct" to "break" things.
> >
> > If developers "want" to break something they will find a way. Protectin=
g
> > "__construct" will not stop them from doing so. But it will stop the re=
st
> > of us do legitimate things.
> >
> > Cheers
> >
> > Andreas
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
>
>
> --
> Giovanni Giacobbi
>



--=20
regards / pozdrawiam,
--
Micha=C5=82 Brzuchalski
about.me/brzuchal
brzuchalski.com

--001a114bd27002a67b054611dd19--