Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:81118
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 217.147.176.214 cause and error)
Message-ID: <54C4BB69.3030701@lsces.co.uk>
Date: Sun, 25 Jan 2015 09:46:17 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <54C4A44F.2030902@gmail.com>
In-Reply-To: <54C4A44F.2030902@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Vote results for default ctors RFC
From: lester@lsces.co.uk (Lester Caine)

On 25/01/15 08:07, Stanislav Malyshev wrote:
> I think not bothering to
> discuss and then just voting "no" with no explanation is not how the
> healthy RFC process should be working.

One thought I had was 'Why would I be adding a constructor is the parent
did not require one?' Personally I would prefer - like with other strict
element - that if I am overriding something which does not currently
exist I get a warning. If the base library 'improves' things by adding
one then I also need to know, so silently hiding it just seems wrong!
The bug in my 'update from 5.2 crib sheet is NOT adding the constructor
to the parent, and that is my starting point even if it's just an empty
shell. As other e_strict additions often turn out.

-- 
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk