"Kalle Sommer Nielsen" wrote in message
news:CAJW__o3QJOe6G3ybmBcoCU=fcadjzacgbktijrbm3rs8q0h...@mail.gmail.com...
Hi Tony
2017-10-31 11:35 GMT+01:00 Tony Marston <tonymars...@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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
