Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:79017
Return-Path: <smalyshev@gmail.com>
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 327 invoked from network); 20 Nov 2014 00:44:30 -0000
Received: from unknown (HELO lists.php.net) (127.0.0.1)
  by localhost with SMTP; 20 Nov 2014 00:44:30 -0000
Authentication-Results: pb1.pair.com smtp.mail=smalyshev@gmail.com; spf=pass; sender-id=pass
Authentication-Results: pb1.pair.com header.from=smalyshev@gmail.com; sender-id=pass
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.176 as permitted sender)
X-PHP-List-Original-Sender: smalyshev@gmail.com
X-Host-Fingerprint: 209.85.192.176 mail-pd0-f176.google.com  
Received: from [209.85.192.176] ([209.85.192.176:50601] helo=mail-pd0-f176.google.com)
	by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP
	id D7/B0-27626-D693D645 for <internals@lists.php.net>; Wed, 19 Nov 2014 19:44:30 -0500
Received: by mail-pd0-f176.google.com with SMTP id y10so1919658pdj.21
        for <internals@lists.php.net>; Wed, 19 Nov 2014 16:44:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=message-id:date:from:user-agent:mime-version:to:cc:subject
         :references:in-reply-to:content-type:content-transfer-encoding;
        bh=PVtUe3BhkYUBAoJd2IQ31P7djibDt4+E+Vs444PtDes=;
        b=hFFmrWZ2lXMnrW2VvHC07qXUS+oSKwwLV6tUun1Jq5jGGcxYxqLdB4YmOltGZt1Rwu
         cfVE2B66QPi0MXqSBPmVafbd8Vbzuh009bpSzDcXIotxkzPW9dRdnofBl0kFZiveNSSd
         HC30Mq4AXlvZt2Nn3mEwVzHChd6iAfyWifz/OoUWaJB6JzIwKo+eXEYb1wuRvPXjCtdl
         RvTM9rHSqb5E5166VuOQLKUCtgZqgAYrNKFNalGlUguQAhOCQXLFOjulh/gYRrKNgd8I
         2L41AlEBNNC6J91JokyvTOcDPmtr0pE1wrl+EoFVxXQL1KQJUDDNfdBZVdg7XZnyNH0X
         ZQdA==
X-Received: by 10.66.234.72 with SMTP id uc8mr51030056pac.51.1416444267283;
        Wed, 19 Nov 2014 16:44:27 -0800 (PST)
Received: from stas-air.corp.wikimedia.org (tan4.corp.wikimedia.org. [198.73.209.4])
        by mx.google.com with ESMTPSA id dp3sm366983pdb.46.2014.11.19.16.44.26
        for <multiple recipients>
        (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
        Wed, 19 Nov 2014 16:44:26 -0800 (PST)
Message-ID: <546D3968.8040702@gmail.com>
Date: Wed, 19 Nov 2014 16:44:24 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Rowan Collins <rowan.collins@gmail.com>, 
 Marco Pivetta <ocramius@gmail.com>
CC: PHP Internals List <internals@lists.php.net>
References: <546B0F62.1090705@gmail.com> <alpine.DEB.2.11.1411181221100.13538@whisky.home.derickrethans.nl> <546B95F2.2050504@gmail.com> <546BBF4F.8040806@gmail.com> <919EDD0D-F0F4-430A-A84B-96A32DF45E7B@ajf.me> <546BCE21.7080403@gmail.com> <546BD0E8.6020609@gmail.com> <546BD206.9040800@gmail.com> <546BD451.4070909@gmail.com> <546BDEAE.2010102@gmail.com> <CADyq6sJ6fYWL+Re-eRXF2hcoRXTwFTrBmsr-OB8OrbyZXTzEQg@mail.gmail.com> <546BF769.9090408@gmail.com> <6120240B-1493-4805-90FF-C0EE38795B89@gmail.com>
In-Reply-To: <6120240B-1493-4805-90FF-C0EE38795B89@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Default constructors
From: smalyshev@gmail.com (Stanislav Malyshev)

Hi!

> The point of this discussion is that there is an RFC on the table
> which can be implemented in such a way that it fixes this behaviour
> (by introducing a default parent, or injecting an empty constructor)
> or such that it carefully preserves it (by making a special case for
> parent::__construct).

I was not planning to do this as part of this RFC. Of course, that
doesn't mean by itself it should not be done, and if it will be done
(after considering all BC consequences, etc.) then the code for this RFC
will need to be changed (while the idea stays). But I do not want to mix
two things - making parent methods always work in places where it makes
sense (ctor, dtor, clone) and refactoring how ctors work to avoid
unpleasant side effect of not evaluating params for missing ctor. These
are two different things, with different consequences, and I don't see
much win in mixing them.

> If you are, as you seem to be, defending this as a feature, it
> implies we should preserve (and, incidentally, standardise) it. If,

No, not really - I don't propose to standardize it. I do propose to
preserve it, for basic BC reasons, and I do say it was an intended
result, not an accidental omission. Now, this result, of course, can be
what we no longer want, and we can change it - but I don't want to make
it a part of my RFC because I consider it an independent issue worthy of
separate consideration.

> This reminds me of the recent discussion over multiple defaults in a
> switch. Perhaps as with that we should phrase the question as "is
> there any useful purpose to having the language standardised with
> this feature, and conversely is there any realistic harm in altering
> it?"

You make it sound as if I'm somehow calling for some change in
"standardizing" this feature. On the contrary, I am just preserving the
status quo, it is as "standard" or "non-standard" as it has ever been.