Re: [PHP-DEV] Re: RFC - Array Of for PHP 7

2017-11-08 Thread Tony Marston 

wrote in message news:0f4b93e2-d8fa-edbd-e1ff-502101839...@rhsoft.net...






well,  you always ignore anything but your opinion and the next step is 
calling people "except if you are a nit-picking, anal retentive OCD 
sufferer" because they don't follow your argumentation as it happened in 
several threads


The whole point of my argument is that I believe it is wrong to fill the 
language with clever functions which do nothing but save a few keystrokes 
for those developers who are too lazy to type out a few simple lines of 
userland code. Filling the language with such bloat has a detrimental effect 
on everybody who uses the language, and especially on the core developers 
who have to maintain that bloat.


You stop telling me that you don't like my opinion and I will stop telling 
you that I don't like your opinion.


--
Tony Marston


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: RFC - Array Of for PHP 7

2017-11-07 Thread Levi Morrison 
The last 10 or so email messages in this thread have been pointless
bickering. Please stop. Thank you!

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: RFC - Array Of for PHP 7

2017-11-07 Thread li...@rhsoft.net 



Am 07.11.2017 um 12:53 schrieb Tony Marston:
It should also be obvious to every first year student that if a program 
contains code that is rarely or never used then carrying around the 
"weight" of that code has a detrimental effect


but you don#t get the basics right: you need to measure if that effect 
is significant at all


The code has a bigger 
footprint, therefore takes up more memory and is slower to load


slower to load don't matter, if the memory overhead is significant needs 
to be measured


It also 
increases the burden on those who maintain that code as they have to 
consider every piece of code without knowing how often it is used.


and *that* is not *your* problem - the whole discussion was about your 
claim that it has a bad effect for everybody out there


GOD DAMNED: stop to ignore "it can even happen that due the 
implementation other code paths which would not have been touched 
otherwise may get optimized due refactoring and the end result can be 
even faster in general" - that you ignored it multiple times proves that 
you can't say anything which would not prove your claims about the 
overall impact wrong


well,  you always ignore anything but your opinion and the next step is 
calling people "except if you are a nit-picking, anal retentive OCD 
sufferer" because they don't follow your argumentation as it happened in 
several threads



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: RFC - Array Of for PHP 7

2017-11-07 Thread Tony Marston 
"Alice Wonder"  wrote in message 
news:572d0e30-7214-0842-6624-7647514b9...@librelamp.com...


On 11/07/2017 02:21 AM, Tony Marston wrote:



Some things are so obvious that they do not need scientific proof.


Some things that appear obvious are incorrect, especially when bias enters. 
Scientific proof brings human bias out of the equation, or at least reduces 
it.



For
example, in a motor vehicle the power-to-weight ratio is important as it
affects engine performance and fuel economy. In other words, for a given
engine size the lower the weight of the car and the better the fuel
consumption. The more weight you add the lower the performance. Your car
has a heater which you only use when it's cold. It also has an air
conditioner for when it's hot. It has windscreen wipers, and a motor,
for when it's raining. When the temperature is mild and it's not raining
it means that you are not using any of this equipment, yet you are still
carrying their weight, and this weight is affecting your car's
performance. I do not have to supply any figures as proof as the car
manufacturers keep telling us that cars that weigh less perform better,
which is why they try to reduce the weight of as any components as
possible.


You then give an example for which every first year physics students has 
done experiments which use science to demonstrate it (namely demonstrating 
how weight impacts friction)


Sorry but if something is obvious then it should be able to test in a 
scientific experiment.


Individuals do not need to provide proof of this claim as it has already 
been made by the motor manufacturers who have provided their own proof. That 
is why they spend fortunes trying to reduce the weight of every single 
component in their cars.


It should also be obvious to every first year student that if a program 
contains code that is rarely or never used then carrying around the "weight" 
of that code has a detrimental effect. The code has a bigger footprint, 
therefore takes up more memory and is slower to load. It also increases the 
burden on those who maintain that code as they have to consider every piece 
of code without knowing how often it is used.


--
Tony Marston


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: RFC - Array Of for PHP 7

2017-11-07 Thread Alice Wonder 

On 11/07/2017 03:43 AM, Tony Marston wrote:



Irrelevant analogy. If you read
https://en.wikipedia.org/wiki/Reduced_instruction_set_computer you will
see the advantage of getting rid of complex and specialised instructions
and concentrating on simple and general instructions.



You will see some advantages.

There are also advantages to adding things.

Often it is easier for programmers to write secure code when the complex 
stuff they could do in user land is already done for them.


Indeed I believe that is part of the design decisions in TLS 1.3.

It's not just that programmers are lazy and want fewer keystrokes, it is 
more likely for the end developer to have fewer mistakes and properly 
maintain his code when the complex stuff isn't his or her worry.


That's not the right solution all the time, but it also isn't the wrong 
solution all the time.


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: RFC - Array Of for PHP 7

2017-11-07 Thread Tony Marston 
"Stephen Reay"  wrote in message 
news:562e5c38-b46b-449d-8676-8699b59dd...@koalephant.com...




On 7 Nov 2017, at 17:21, Tony Marston  wrote:

I was around when that happened, so I know what I'm talking about.


I'm not going to get into the whole "it can be done in userland why do we 
need it in core" debate, because honestly that's a silly discussion to have 
when you don't have any planned implementation to discuss the merits of.


So you are quite happy to see the language filled with complicated features 
which do nothing but save a few keystrokes or lazy developers?



The only reason I wanted to respond was your last line, quoted above.

Being "around" when something happens means zero as far as credibility or 
knowledge.


The captain of the titanic was "around" when it sank.


Irrelevant analogy. If you read 
https://en.wikipedia.org/wiki/Reduced_instruction_set_computer you will see 
the advantage of getting rid of complex and specialised instructions and 
concentrating on simple and general instructions.


--
Tony Marston


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: RFC - Array Of for PHP 7

2017-11-07 Thread Stephen Reay 

> On 7 Nov 2017, at 17:21, Tony Marston  wrote:
> 
> I was around when that happened, so I know what I'm talking about.

I'm not going to get into the whole "it can be done in userland why do we need 
it in core" debate, because honestly that's a silly discussion to have when you 
don't have any planned implementation to discuss the merits of.

The only reason I wanted to respond was your last line, quoted above.

Being "around" when something happens means zero as far as credibility or 
knowledge.

The captain of the titanic was "around" when it sank.



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: RFC - Array Of for PHP 7

2017-11-07 Thread Alice Wonder 

On 11/07/2017 02:21 AM, Tony Marston wrote:



Some things are so obvious that they do not need scientific proof.


Some things that appear obvious are incorrect, especially when bias 
enters. Scientific proof brings human bias out of the equation, or at 
least reduces it.



For
example, in a motor vehicle the power-to-weight ratio is important as it
affects engine performance and fuel economy. In other words, for a given
engine size the lower the weight of the car and the better the fuel
consumption. The more weight you add the lower the performance. Your car
has a heater which you only use when it's cold. It also has an air
conditioner for when it's hot. It has windscreen wipers, and a motor,
for when it's raining. When the temperature is mild and it's not raining
it means that you are not using any of this equipment, yet you are still
carrying their weight, and this weight is affecting your car's
performance. I do not have to supply any figures as proof as the car
manufacturers keep telling us that cars that weigh less perform better,
which is why they try to reduce the weight of as any components as
possible.


You then give an example for which every first year physics students has 
done experiments which use science to demonstrate it (namely 
demonstrating how weight impacts friction)


Sorry but if something is obvious then it should be able to test in a 
scientific experiment.


It use to be obvious that some animals were closely related until 
scientific tests were done, showing that they weren't, and we discovers 
convergent evolution.


Sorry, I don't mean to go off topic, but saying the scientific method 
isn't needed to back up certain claims because they are obvious is a 
very dangerous point of view.



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: RFC - Array Of for PHP 7

2017-11-07 Thread li...@rhsoft.net 



Am 07.11.2017 um 11:21 schrieb Tony Marston:

wrote in message news:748869f7-13bb-5bdd-6fec-399a33b79...@rhsoft.net...
Everybody knows that carrying around code which is either rarely used 
or not used at all is an overhead


everybody knows that claims without measure the impact are worthless


Some things are so obvious that they do not need scientific proof. For 
example, in a motor vehicle the power-to-weight ratio is important as it 
affects engine performance and fuel economy. In other words, for a given 
engine size the lower the weight of the car and the better the fuel 
consumption. The more weight you add the lower the performance. Your car 
has a heater which you only use when it's cold


pretty sure you know why you removed "it can even happen that due the 
implementation other code paths which would not have been touched 
otherwise may get optimized due refactoring and the end result can be 
even faster in general" beause it may make all your claims and car 
comparison worthless at the end of the day


software development is not pure physics and as example code-inlining as 
a optimization step of modern compilers proves that all your claims are 
wrong until the implementation exists and can be measured


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: RFC - Array Of for PHP 7

2017-11-07 Thread Tony Marston 

wrote in message news:748869f7-13bb-5bdd-6fec-399a33b79...@rhsoft.net...




Am 06.11.2017 um 12:09 schrieb Tony Marston:

wrote in message news:55fb932f-7f61-33eb-1fd9-aa425bc6f...@rhsoft.net...

Am 05.11.2017 um 11:24 schrieb Tony Marston:
wrote in message 
news:d70cc49d-c397-3f09-d08d-b79b31014...@rhsoft.net...
it depends on the implementation and just beause you say so does not 
prove anything and even if you need to measure, optimize and make 
decisions based on technical facts - what you do is "mimimi i say"


I have worked on software which provided lots of different options, 
which means that you have to keep testing if an option is being used or 
not. This is an overhead whether you like it or not.


maybe your implementation was bad


Everybody knows that carrying around code which is either rarely used or 
not used at all is an overhead


everybody knows that claims without measure the impact are worthless


Some things are so obvious that they do not need scientific proof. For 
example, in a motor vehicle the power-to-weight ratio is important as it 
affects engine performance and fuel economy. In other words, for a given 
engine size the lower the weight of the car and the better the fuel 
consumption. The more weight you add the lower the performance. Your car has 
a heater which you only use when it's cold. It also has an air conditioner 
for when it's hot. It has windscreen wipers, and a motor, for when it's 
raining. When the temperature is mild and it's not raining it means that you 
are not using any of this equipment, yet you are still carrying their 
weight, and this weight is affecting your car's performance. I do not have 
to supply any figures as proof as the car manufacturers keep telling us that 
cars that weigh less perform better, which is why they try to reduce the 
weight of as any components as possible.


It is the same with software. The more code you carry around that is not 
being used then the worse it will perform. Esoteric code which uses clever 
features to perform tasks which can already be performed with simple code 
is, IMHO, an unnecessary complication which benefits only those lazy 
programmers who are obsessed with reducing the number of keystrokes. Taking 
out the rarely used complicated stuff and concentrating on making the 
commonly used stuff as fast and efficient as possible is what drove the 
efforts in the RISC architecture. I was around when that happened, so I know 
what I'm talking about.



--
Tony Marston


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: RFC - Array Of for PHP 7

2017-11-06 Thread li...@rhsoft.net 



Am 06.11.2017 um 12:09 schrieb Tony Marston:

wrote in message news:55fb932f-7f61-33eb-1fd9-aa425bc6f...@rhsoft.net...

Am 05.11.2017 um 11:24 schrieb Tony Marston:

wrote in message news:d70cc49d-c397-3f09-d08d-b79b31014...@rhsoft.net...
it depends on the implementation and just beause you say so does not 
prove anything and even if you need to measure, optimize and make 
decisions based on technical facts - what you do is "mimimi i say"


I have worked on software which provided lots of different options, 
which means that you have to keep testing if an option is being used 
or not. This is an overhead whether you like it or not.


maybe your implementation was bad


Everybody knows that carrying around code which is either rarely used or 
not used at all is an overhead


everybody knows that claims without measure the impact are worthless

it can even happen that due the implementation other code paths which 
would not have been touched otherwise may get optimized due refactoring 
and the end result can be even faster in general


or why did 5.3, 5.4, 5.5 and 5.6 not speaking about 7.0/7.1 *all* 
have new features and where *faster* then the previous version - 
frankly you are raising alarm for no reason


Can you prove that each new version was faster? Where is your evidence?


everbody knows that and can benchmark it at any time, but if it makes 
you happy that others are doing your homework


https://www.phpclasses.org/blog/post/493-php-performance-evolution.html


interesting that you ignore that now completly

how does that change the fact that your claim "such as it being 64bit 
instead of 32bit" is nonsense when most of the benchamrks and 
production servers out there are running PHP on x86_64 with 86_64 
builds for a decade now?


64bit builds of PHP 5 for Windows were all marked as experimental, 
therefore not  guaranteed to be as reliable as the 32bit versions. The 
"experimental" tag was only removed for PHP 7.


yes, but the majority of production servers is running on Linux, 
especially in times where they are mostly virtualized


Just think how much faster and easier to maintain it would be if all 
this save-a-few-keystrokes dross had not been added in the first place.


again: unproven claim, but in your own world a hashtable probably is 
also not O(1) or you are just not capable to optimize software at all 
but then stop claim others aren't too


Everybody knows that carrying around code which is either rarely used or 
not used at all is an overhead. That's what the 80-20 rule demonstrates


everybody knows that claims without measure the impact are worthless

it can even happen that due the implementation other code paths which 
would not have been touched otherwise may get optimized due refactoring 
and the end result can be even faster in general


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: RFC - Array Of for PHP 7

2017-11-06 Thread Tony Marston 

wrote in message news:55fb932f-7f61-33eb-1fd9-aa425bc6f...@rhsoft.net...




Am 05.11.2017 um 11:24 schrieb Tony Marston:

wrote in message news:d70cc49d-c397-3f09-d08d-b79b31014...@rhsoft.net...
it depends on the implementation and just beause you say so does not 
prove anything and even if you need to measure, optimize and make 
decisions based on technical facts - what you do is "mimimi i say"


I have worked on software which provided lots of different options, which 
means that you have to keep testing if an option is being used or not. 
This is an overhead whether you like it or not.


maybe your implementation was bad


Everybody knows that carrying around code which is either rarely used or not 
used at all is an overhead. That's what the 80-20 rule demonstrates.


Adding something to the language core for something which can already be 
done easily is userland code, but with slightly fewer keystrokes, does not 
provide any benefits for the majority of developers who have already written 
those few lines of code. This is a classic example of pandering to the whims 
of a tiny minority to the detriment of the majority.


There is a big difference between adding something to the language core 
which everyone has to load into memory, and having something in an 
extension which is entirely optional.


or why did 5.3, 5.4, 5.5 and 5.6 not speaking about 7.0/7.1 *all* have 
new features and where *faster* then the previous version - frankly 
you are raising alarm for no reason


Can you prove that each new version was faster? Where is your evidence?


everbody knows that and can benchmark it at any time, but if it makes you 
happy that others are doing your homework


https://www.phpclasses.org/blog/post/493-php-performance-evolution.html

PHP 7 is faster than PHP 5 for various reasons, such as it being 64bit 
instead of 32bit


WTF, only in your windows world which don't matter that much, everywhere 
else x86_64 is normal for many years and each software


Excuse me! Some of the major clients who use my ERP application only use 
Windows servers, so your claim that Windows does matter is completely 
bogus.


how does that change the fact that your claim "such as it being 64bit 
instead of 32bit" is nonsense when most of the benchamrks and production 
servers out there are running PHP on x86_64 with 86_64 builds for a decade 
now?


64bit builds of PHP 5 for Windows were all marked as experimental, therefore 
not  guaranteed to be as reliable as the 32bit versions. The "experimental" 
tag was only removed for PHP 7.


and improvements made to the engine itself, such as the AST. I submit 
that it would be smaller and faster if it did not have to carry around 
so much dross. Adding something to the core language just to save a few 
keystrokes for a small number of lazy developers falls into the 
category of dross


you ignored that practicaly *every* PHP version before PHP/ was faster 
*and* had new features compared to the previous one


Just think how much faster and easier to maintain it would be if all this 
save-a-few-keystrokes dross had not been added in the first place.


again: unproven claim, but in your own world a hashtable probably is also 
not O(1) or you are just not capable to optimize software at all but then 
stop claim others aren't too


Everybody knows that carrying around code which is either rarely used or not 
used at all is an overhead. That's what the 80-20 rule demonstrates.


--
Tony Marston


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: RFC - Array Of for PHP 7

2017-11-05 Thread li...@rhsoft.net 



Am 05.11.2017 um 11:24 schrieb Tony Marston:

wrote in message news:d70cc49d-c397-3f09-d08d-b79b31014...@rhsoft.net...
it depends on the implementation and just beause you say so does not 
prove anything and even if you need to measure, optimize and make 
decisions based on technical facts - what you do is "mimimi i say"


I have worked on software which provided lots of different options, 
which means that you have to keep testing if an option is being used or 
not. This is an overhead whether you like it or not.


maybe your implementation was bad

There is a big difference between adding something to the language 
core which everyone has to load into memory, and having something in 
an extension which is entirely optional.


or why did 5.3, 5.4, 5.5 and 5.6 not speaking about 7.0/7.1 *all* 
have new features and where *faster* then the previous version - 
frankly you are raising alarm for no reason


Can you prove that each new version was faster? Where is your evidence?


everbody knows that and can benchmark it at any time, but if it makes 
you happy that others are doing your homework


https://www.phpclasses.org/blog/post/493-php-performance-evolution.html

PHP 7 is faster than PHP 5 for various reasons, such as it being 
64bit instead of 32bit


WTF, only in your windows world which don't matter that much, 
everywhere else x86_64 is normal for many years and each software


Excuse me! Some of the major clients who use my ERP application only use 
Windows servers, so your claim that Windows does matter is completely 
bogus.


how does that change the fact that your claim "such as it being 64bit 
instead of 32bit" is nonsense when most of the benchamrks and production 
servers out there are running PHP on x86_64 with 86_64 builds for a 
decade now?


and improvements made to the engine itself, such as the AST. I submit 
that it would be smaller and faster if it did not have to carry 
around so much dross. Adding something to the core language just to 
save a few keystrokes for a small number of lazy developers falls 
into the category of dross


you ignored that practicaly *every* PHP version before PHP/ was faster 
*and* had new features compared to the previous one


Just think how much faster and easier to maintain it would be if all 
this save-a-few-keystrokes dross had not been added in the first place.


again: unproven claim, but in your own world a hashtable probably is 
also not O(1) or you are just not capable to optimize software at all 
but then stop claim others aren't too


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: RFC - Array Of for PHP 7

2017-11-05 Thread Tony Marston 

wrote in message news:d70cc49d-c397-3f09-d08d-b79b31014...@rhsoft.net...




Am 04.11.2017 um 10:18 schrieb Tony Marston:

wrote in message news:941fd347-4a17-78b6-1bd7-4a5519aa7...@rhsoft.net...


Am 03.11.2017 um 11:33 schrieb Tony Marston:
wrote in message 
news:6643d10b-8703-693c-15c2-da338022e...@rhsoft.net...


Am 02.11.2017 um 10:55 schrieb Tony Marston:

"Kalle Sommer Nielsen"  wrote in message

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


how does any feature you don't use affect you?


Because the language itself becomes bloated with the capabilities it 
has to offer, look for and deal with. This makes it bigger and slower


unproven claim!


It's pure common sense! You have to carry around the capability of doing 
something, then have tests everywhere to see if that capability is 
actually required or not at run-time.


it depends on the implementation and just beause you say so does not prove 
anything and even if you need to measure, optimize and make decisions based 
on technical facts - what you do is "mimimi i say"


I have worked on software which provided lots of different options, which 
means that you have to keep testing if an option is being used or not. This 
is an overhead whether you like it or not.


There is a big difference between adding something to the language core 
which everyone has to load into memory, and having something in an 
extension which is entirely optional.


or why did 5.3, 5.4, 5.5 and 5.6 not speaking about 7.0/7.1 *all* have 
new features and where *faster* then the previous version - frankly you 
are raising alarm for no reason


Can you prove that each new version was faster? Where is your evidence?

PHP 7 is faster than PHP 5 for various reasons, such as it being 64bit 
instead of 32bit


WTF, only in your windows world which don't matter that much, everywhere 
else x86_64 is normal for many years and each software


Excuse me! Some of the major clients who use my ERP application only use 
Windows servers, so your claim that Windows does matter is completely bogus.


and improvements made to the engine itself, such as the AST. I submit 
that it would be smaller and faster if it did not have to carry around so 
much dross. Adding something to the core language just to save a few 
keystrokes for a small number of lazy developers falls into the category 
of dross


you ignored that practicaly *every* PHP version before PHP/ was faster 
*and* had new features compared to the previous one


Just think how much faster and easier to maintain it would be if all this 
save-a-few-keystrokes dross had not been added in the first place.


--
Tony Marston


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: RFC - Array Of for PHP 7

2017-11-04 Thread li...@rhsoft.net 



Am 04.11.2017 um 10:18 schrieb Tony Marston:

wrote in message news:941fd347-4a17-78b6-1bd7-4a5519aa7...@rhsoft.net...


Am 03.11.2017 um 11:33 schrieb Tony Marston:

wrote in message news:6643d10b-8703-693c-15c2-da338022e...@rhsoft.net...


Am 02.11.2017 um 10:55 schrieb Tony Marston:

"Kalle Sommer Nielsen"  wrote in message

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


how does any feature you don't use affect you?


Because the language itself becomes bloated with the capabilities it 
has to offer, look for and deal with. This makes it bigger and slower


unproven claim!


It's pure common sense! You have to carry around the capability of doing 
something, then have tests everywhere to see if that capability is 
actually required or not at run-time.


it depends on the implementation and just beause you say so does not 
prove anything and even if you need to measure, optimize and make 
decisions based on technical facts - what you do is "mimimi i say"


There is a big difference between adding something to the language core 
which everyone has to load into memory, and having something in an 
extension which is entirely optional.


or why did 5.3, 5.4, 5.5 and 5.6 not speaking about 7.0/7.1 *all* have 
new features and where *faster* then the previous version - frankly 
you are raising alarm for no reason


PHP 7 is faster than PHP 5 for various reasons, such as it being 64bit 
instead of 32bit


WTF, only in your windows world which don't matter that much, everywhere 
else x86_64 is normal for many years and each software


and improvements made to the engine itself, such as 
the AST. I submit that it would be smaller and faster if it did not have 
to carry around so much dross. Adding something to the core language 
just to save a few keystrokes for a small number of lazy developers 
falls into the category of dross


you ignored that practicaly *every* PHP version before PHP/ was faster 
*and* had new features compared to the previous one


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: RFC - Array Of for PHP 7

2017-11-04 Thread Tony Marston 

wrote in message news:941fd347-4a17-78b6-1bd7-4a5519aa7...@rhsoft.net...




Am 03.11.2017 um 11:33 schrieb Tony Marston:

wrote in message news:6643d10b-8703-693c-15c2-da338022e...@rhsoft.net...


Am 02.11.2017 um 10:55 schrieb Tony Marston:

"Kalle Sommer Nielsen"  wrote in message

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


how does any feature you don't use affect you?


Because the language itself becomes bloated with the capabilities it has 
to offer, look for and deal with. This makes it bigger and slower


unproven claim!


It's pure common sense! You have to carry around the capability of doing 
something, then have tests everywhere to see if that capability is actually 
required or not at run-time.


There is a big difference between adding something to the language core 
which everyone has to load into memory, and having something in an extension 
which is entirely optional.


or why did 5.3, 5.4, 5.5 and 5.6 not speaking about 7.0/7.1 *all* have new 
features and where *faster* then the previous version - frankly you are 
raising alarm for no reason


PHP 7 is faster than PHP 5 for various reasons, such as it being 64bit 
instead of 32bit, and improvements made to the engine itself, such as the 
AST. I submit that it would be smaller and faster if it did not have to 
carry around so much dross. Adding something to the core language just to 
save a few keystrokes for a small number of lazy developers falls into the 
category of dross.


--
Tony Marston


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: RFC - Array Of for PHP 7

2017-11-03 Thread li...@rhsoft.net 



Am 03.11.2017 um 11:33 schrieb Tony Marston:

wrote in message news:6643d10b-8703-693c-15c2-da338022e...@rhsoft.net...


Am 02.11.2017 um 10:55 schrieb Tony Marston:

"Kalle Sommer Nielsen"  wrote in message

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


how does any feature you don't use affect you?


Because the language itself becomes bloated with the capabilities it has 
to offer, look for and deal with. This makes it bigger and slower


unproven claim!

or why did 5.3, 5.4, 5.5 and 5.6 not speaking about 7.0/7.1 *all* have 
new features and where *faster* then the previous version - frankly you 
are raising alarm for no reason


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: RFC - Array Of for PHP 7

2017-11-03 Thread Tony Marston 

wrote in message news:6643d10b-8703-693c-15c2-da338022e...@rhsoft.net...




Am 02.11.2017 um 10:55 schrieb Tony Marston:

"Kalle Sommer Nielsen"  wrote in message

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


how does any feature you don't use affect you?


Because the language itself becomes bloated with the capabilities it has to 
offer, look for and deal with. This makes it bigger and slower. For example, 
if you have a vehicle which is capable of going anywhere, over every types 
of terrain, in every climate from sub zero to blisteringly hot then at any 
one time you are not using all the capabilities, yet you are still carrying 
the around.


The core language should be kept lean and mean, and should only have new 
instructions added when (a) something cannot be done easily in userland 
code, and (b) when that something is of genuine use to a significant number 
of people. Complicating the language with something that can already be done 
with a few lines of userland code and which is desired by only a miniscule 
number of people does not fall into this category.


i don't care about pdo and many other core extensions nor about namespaces, 
traits and so on - but they don't affect me at all


--
Tony Marston


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: RFC - Array Of for PHP 7

2017-11-02 Thread li...@rhsoft.net 



Am 02.11.2017 um 10:55 schrieb Tony Marston:
"Kalle Sommer Nielsen"  wrote in message 

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


how does any feature you don't use affect you?

i don't care about pdo and many other core extensions nor about 
namespaces, traits and so on - but they don't affect me at all



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: RFC - Array Of for PHP 7

2017-11-02 Thread Tony Marston 
"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 :

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

Re: [PHP-DEV] Re: RFC - Array Of for PHP 7

2017-10-31 Thread Kalle Sommer Nielsen 
Hi Tony

2017-10-31 11:35 GMT+01:00 Tony Marston :
> 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, 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.

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.

> 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 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
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. 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.


[1] https://gist.github.com/KalleZ/c7ba4f78314c989e27710e4fa14e2f3e



-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: RFC - Array Of for PHP 7

2017-10-31 Thread Thomas Hruska 

On 10/31/2017 3:35 AM, Tony Marston wrote:
""Michal Harezlak""  wrote in message 
news:caltzvrkflncw4+d-fu4cp2rmoscf77vzfz4f1cuvp3vymzk...@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/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php