Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:79023
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain legalweb.org.uk designates 188.39.106.5 as permitted sender)
Message-ID: <546DA9EA.105@legalweb.org.uk>
Date: Thu, 20 Nov 2014 08:44:26 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: 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> <546D3968.8040702@gmail.com>
In-Reply-To: <546D3968.8040702@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Default constructors
From: bradley@legalweb.org.uk (Bradley Weston)

Somehow HHVM has this working http://3v4l.org/5AFSA


On 20/11/2014 00:44, Stanislav Malyshev wrote:
> 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.
>

-- 
Regards,

Bradley.

Direct: 0116 224 7372
Office: 0845 004 0662
Mobile: 07902 672289
E-Mail: brad@legalweb.org.uk
WebSite: legalweb.org.uk

This message is intended only for the use of person(s) ("the Intended Recipient") to whom it is addressed. It may contain information that is privileged and confidential within the meaning of applicable law. Accordingly any dissemination, distribution, copying or other use of this message or any of its content by any other person may constitute a breach of civil or criminal law and is strictly prohibited. If you are not the Intended Recipient please contact the sender as soon as possible. Any views expressed in this message are those of the individual sender and may not necessarily reflect the views of Legalwebb UK Ltd or any of its subsidiary businesses. Legalwebb UK Limited is Registered in Cardiff. Company Number 03874311. Registered for VAT Number 803886708