Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:101027
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <71.50.09857.3BBEAF95@pb1.pair.com>
To: internals@lists.php.net
References: <CALTzvrKFLnCW4+D-FU4cp2rmOScF77vZFz4f1cuVP3VyMzkkeg@mail.gmail.com> <64.21.07742.EF158F95@pb1.pair.com> <CAJW__o3QJOe6G3ybmBcoCU=FCAdjZAcgbKTiJRBM3RS8Q0hBNQ@mail.gmail.com>
In-Reply-To: <CAJW__o3QJOe6G3ybmBcoCU=FCAdjZAcgbKTiJRBM3RS8Q0hBNQ@mail.gmail.com>
Date: Thu, 2 Nov 2017 09:55:59 -0000
Lines: 6
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="utf-8";
	reply-type=original
Content-Transfer-Encoding: 7bit
Importance: Normal
Subject: Re: [PHP-DEV] Re: RFC - Array Of for PHP 7
From: TonyMarston@hotmail.com ("Tony Marston")

"Kalle Sommer Nielsen"  wrote in message 
news:CAJW__o3QJOe6G3ybmBcoCU=FCAdjZAcgbKTiJRBM3RS8Q0hBNQ@mail.gmail.com...
>
>Hi Tony
>
>2017-10-31 11:35 GMT+01:00 Tony Marston <TonyMarston@hotmail.com>:
>> 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 do understand where you are coming from, but I don't necessarily
>agree on this topic. We can (hopefully) agree that programming
>language design is hard,

I totally agree that compiler writing is hard, which is why I believe that 
only those things which are hard to do in userland code should be added to 
the language.

>because we need to determine how fine a line
>we should have between things thats an integral part of the language,
>its standard library or its extensions and how much power the
>programmer has in their arsenal to do crazy things.

For me the rule is simple - if something can already be done quite easily in 
userland code then it should not be forced into the language just because a 
small number of developers wnat to save themselves a few keystrokes. Making 
the language more complicated than it need be leads to a maintenance burden 
both for the core developers and the application developers who now have to 
deal with a growing array of indeciferable shortcuts.

>If we boil things down, then we didn't really need the scalar type
>hints, PHP had been working perfectly fine for 20 years without it and
>while it does not add anything but a couple of checks at
>compile/runtime, its essentially "laziness of certain programmers" it
>becomes useful to. Another example is constant visibility modifiers in
>PHP 7.1.
>
>I think one of the advocates for features that are within that
>category you mention can sometimes be productivity and rid of
>boilerplate code. For this case with 'Array Of', I think it makes
>perfect sense to add with PHP7's improved type system on that regard,
>but thats my personal opinion.

This type of checking can quite easily be done in userland code, so I see no 
reason why it should be built into the language. What percentage of userland 
developers would actually use such a feature? I wouldn't as I never pass 
around arrays of single types. I regularly use the $_POST array and a 
database record array which are both of mixed types.

>> 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.
>
>Tho you said its a micro optimization, would argue that (see [1]), it
>far from makes the code complicated,

>internally it doesn't add any complexity

I disagree. The language has to be changed to recognise that type of 
argument, then it has to iterate through the array checking that every 
member is of the designated type. In other words the langage now has to do 
what you are doing with a few lines of userland code.

>and only adds a member to the arg_info, which is an
>unsigned char, it wouldn't do anything unless a type is specified
>anyway and the slower to run argument above is pretty void, sure it
>adds a few CPU instructions but its not something you will feel unless
>you are Facebook, in which case you already re-implemented the
>language on your own.
>
>I fail to see how it offers "negative benefits to the vast number of
>programmers who are happy with the language as it currently exists", I

If it's put into the language then it affects 100% of the users, but what 
percentage of the user base would actually take advantage of this feature? 
If it's only 1% then for the other 99% it's a complete waste of time.

>myself don't like PDO, so I just use mysqli instead, great. If its not
>something that affects the programmer and the programmers code
>continue to run, I fail to see how it negatively impacts the vast
>majority.

It has complications in the language that are not used. Have you ever heard 
o the 80-20 rule? This is where 80% of the usage is simple and 20% is 
complicated, but that complicated 20% takes up 80% of the programming 
effort.  I was around in the 1980s during the switch to RISC (Reduced 
Instruction Set Computers) where it was found that by removing the 
complicated instructions which could be executed in a single cycle and 
replacing them with a series of simple instructions there were enormous 
benefits all round - the chips became smaller, were cheaper to manufacture, 
the cycles faster, the energy consumption smaller and with less heat 
generated. It was a win-win all round.

By keeping out the frivolous froth from the language and restricting it to a 
set of really useful features you end up with a smaller language which is 
faster to run and easier to maintain. IMHO this RFC does not benefit the 
greater PHP community, it just saves a few keystrokes for the lazy 
developer.

>If I asked you how you feel about the exif extension now
>supports streams as arguments instead of only file names, would you
>care much unless you are actively using the exif extension? Probably
>not.

There is a great deal of difference between an extension which does 
something complicated which cannot easily be done in userland code and 
changing the core language just to save a few keystrokes. There are dozens 
of extensions that I don't use, but I would never call for them to be 
scrapped. Changing the core language is something else altogether. It's 
there whether I want it or not, and it affects the execution of every 
function or method call.

>[1] https://gist.github.com/KalleZ/c7ba4f78314c989e27710e4fa14e2f3e
>

-- 
Tony Marston