Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:101000
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain cubiclesoft.com designates 149.56.142.28 as permitted sender)
To: Tony Marston <TonyMarston@hotmail.com>, internals@lists.php.net
References: <CALTzvrKFLnCW4+D-FU4cp2rmOScF77vZFz4f1cuVP3VyMzkkeg@mail.gmail.com>
 <64.21.07742.EF158F95@pb1.pair.com>
Message-ID: <22a9a179-a41d-3b35-4e9c-47be87b2407d@cubiclesoft.com>
Date: Tue, 31 Oct 2017 07:39:39 -0700
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120327
 Thunderbird/11.0.1
MIME-Version: 1.0
In-Reply-To: <64.21.07742.EF158F95@pb1.pair.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] Re: RFC - Array Of for PHP 7
From: thruska@cubiclesoft.com (Thomas Hruska)

On 10/31/2017 3:35 AM, Tony Marston wrote:
> ""Michal Harezlak""  wrote in message 
> news:CALTzvrKFLnCW4+D-FU4cp2rmOScF77vZFz4f1cuVP3VyMzkkeg@mail.gmail.com...
>>
>> Hallo,
>>
>> I would like to create a RFC for PHP 7, but the same RFC was created and
>> declined 3 years ago for PHP 5.4. PHP 7 support much better type 
>> hinging so
>> I think this RFC should be voted again.
>>
>> What should I do? Should I create the RPF in common way?
>>
>> Link to mentioned RFC:
>> https://wiki.php.net/rfc/arrayof
> 
> This strikes me as being nothing more than a micro-optimisation that 
> does nothing but pander to the laziness of certain programmers. Instead 
> of having to write a few lines of code to validate something they want 
> the language to do it for them. It may come as a surprise to some 
> people, but being a programmer actually involves the writing of program 
> code. It is not sufficient to express an idea and have the language fill 
> in all the details as that forces the language to have to detect and 
> deal with a myriad of possibilities.
> 
> I would evaluate each proposed change to the language with a simple 
> question - does it provide the greatest good to the greatest number? 
> Considering the fact that this RFC will only benefit a miniscule 
> minority of developers yet make the language more complicated, slower to 
> run, and more difficult to maintain as more and more edge cases are 
> identified as "bugs", it offers negative benefits to the vast number of 
> programmers who are happy with the language as it currently exists. As 
> such it fails that test and should be rejected.

I agree.

Features that result in significant improvements to algorithmic 
complexity but can't be implemented in userland are the sort of features 
that should be priority for core.  That's another way to look at the 
question that Tony put forth but in more concrete terms.  Internals 
already tends to adhere to that sort of policy anyway even if it isn't 
formally written anywhere.

-- 
Thomas Hruska
CubicleSoft President

I've got great, time saving software that you will find useful.

http://cubiclesoft.com/

And once you find my software useful:

http://cubiclesoft.com/donate/