Sent: Thursday, February 25, 2016 12:58 PM
To: Tony Marston
Subject: Re: [PHP-DEV] [RFC Proposal] var keyword deprecation/removal
Hi Tony,Thank you so much for your feedback. You make some really good, valid
points. If I may provide some responses to some of them:Where is your proof? You say "not used by a major part of the community"
which means that it is still being used by a minor part, but exactly how
"minor"?I downloaded and scanned the top 10,000 projects on Packagist (including
their dependencies).
So you examined a bunch of source files in one location? What about those
projects that aren't maintained on Packagist? Mine certainly isn't.
Only 4% use "var". I looked closer into that 4% and found almost 2/3rds
were due to a handful of prominent packages being required as dependencies.
Adjusting these packages would drastically lower overall usage across the
ecosystem. And because "var" is simply an alias for "public", making that
change would only require a bump in the patch version.I'm not 100% happy with my methodology because the dependencies are counted
multiple times. When I have some time I'll revise my approach to get
more-accurate figures.
The only way to obtain what could be called "accurate" figures would be to
examine every PHP script ever written. What you have is nothing more than a
small sample.
it would take effort to take it out...
Here's a simple PHP script which does this automatically:
https://gist.github.com/colinodell/5fb5e5d474674f294a38 Because "public"
is supported in 5.x and 7.x, programmers could run this script at any time
before the 8.0 release (assuming this proposed RFC passes and the
programmer wants their code to run on 8.0)....and amend the documentation
I will happily make that change myself.
while programmers expect new features to be added they do NOT expect old
features
to disappear. Once a piece of code has been written and has proved to
work
as designed it is expected to work with all future versions.I'm hoping that the automated upgrade script and advance warning would help
mitigate that impact.
I, and others, will object to having to run any sort of conversion scripts
just because you personally don't like the "var" keyword. It does no harm,
so there is no benefit to be had by taking it out.
--
Tony Marston
Good morning Internals!
I am strongly AGAINST the removal of the var keyword from PHP
syntax. Though in general it's an alias of public (or it simply
‘acts’ as the public modifier), I see a difference in its
semantics. While the public modifier states anyone can change the
property, var is useful for marking internal properties which must
be public, but should not be manipulated by simply anybody e.g. in the
case of dependency injection:
<?php
class HomepagePresenter extends Nette\Application\UI\Presenter {
/** @var Model\FooService @inject */
var $fooService;
public function renderFooExample() {
// now you can use $this->fooService thanks to DI container
}
}
?>
This idea comes to me from using the Nette Framework, which handles DI
automatically and this way -- using var -- one can semantically
mark, which are the internally @inject'ed properties and differ them
from the public ones.
Sent: Thursday, February 25, 2016 12:58 PM
To: Tony Marston
Subject: Re: [PHP-DEV] [RFC Proposal] var keyword deprecation/removal
Hi Tony,Thank you so much for your feedback. You make some really good, valid
points. If I may provide some responses to some of them:Where is your proof? You say "not used by a major part of the community"
which means that it is still being used by a minor part, but exactly how
"minor"?I downloaded and scanned the top 10,000 projects on Packagist (including
their dependencies).So you examined a bunch of source files in one location? What about those
projects that aren't maintained on Packagist? Mine certainly isn't.Only 4% use "var". I looked closer into that 4% and found almost 2/3rds
were due to a handful of prominent packages being required as dependencies.
Adjusting these packages would drastically lower overall usage across the
ecosystem. And because "var" is simply an alias for "public", making that
change would only require a bump in the patch version.I'm not 100% happy with my methodology because the dependencies are
counted multiple times. When I have some time I'll revise my approach to
get more-accurate figures.The only way to obtain what could be called "accurate" figures would be to
examine every PHP script ever written. What you have is nothing more than a
small sample.it would take effort to take it out...
Here's a simple PHP script which does this automatically:
https://gist.github.com/colinodell/5fb5e5d474674f294a38 Because "public" is
supported in 5.x and 7.x, programmers could run this script at any time
before the 8.0 release (assuming this proposed RFC passes and the programmer
wants their code to run on 8.0)....and amend the documentation
I will happily make that change myself.
while programmers expect new features to be added they do NOT expect old
features
to disappear. Once a piece of code has been written and has proved to
work
as designed it is expected to work with all future versions.I'm hoping that the automated upgrade script and advance warning would
help mitigate that impact.I, and others, will object to having to run any sort of conversion scripts
just because you personally don't like the "var" keyword. It does no harm,
so there is no benefit to be had by taking it out.--
Tony Marston--
Thanks!
--
Cheers,
Kubis
I see a difference in its
semantics. While thepublicmodifier states anyone can change the
property,varis useful for marking internal properties which must
be public, but should not be manipulated by simply anybody
If it's public, it will be modified by someone. This isn't an intended
semantic meaning of var, and simply saying "don't modify this please" is
never going to be enough. Make them private, protected or public and make
your intent clear, because for anyone unfamiliar with this design will
simply translate var to mean public, and use it as such.
"James Titcumb" wrote in message
news:CAKnqCEY7art1GUWG=Pm0wyPGQmYp0Dq8oxdohgBkSGq+O_BTZw@mail.gmail.com...
I see a difference in its
semantics. While thepublicmodifier states anyone can change the
property,varis useful for marking internal properties which must
be public, but should not be manipulated by simply anybodyIf it's public, it will be modified by someone.
Incorrect. It may be modified, but surely any invalid modifications will
be detected in the testing phase?
This isn't an intended
semantic meaning ofvar, and simply saying "don't modify this please" is
never going to be enough. Make them private, protected or public and make
your intent clear, because for anyone unfamiliar with this design will
simply translatevarto meanpublic, and use it as such.
If "var" is automatically translated into "public", and has been since PHP 5
emerged, and has been documented to behave in this way, then what does it
cost to leave it that way? Answer: NOTHING!
--
Tony Marston
Tony Marston wrote on 29/02/2016 09:55:
"James Titcumb" wrote in message
news:CAKnqCEY7art1GUWG=Pm0wyPGQmYp0Dq8oxdohgBkSGq+O_BTZw@mail.gmail.com...I see a difference in its
semantics. While thepublicmodifier states anyone can change the
property,varis useful for marking internal properties which must
be public, but should not be manipulated by simply anybodyIf it's public, it will be modified by someone.
Incorrect. It may be modified, but surely any invalid modifications
will be detected in the testing phase?
Detected by whom? Using what tool? I'm not aware of any generic way of
logging all access to particular properties, nor quite what "invalid
modifications" mean in this labelling scheme. Maybe it would be detected
during review? Apologies if that's what you meant and the distinction
sounds pedantic.
A better way to mark this kind of distinction is using PHPDoc
annotations, which can be made readable by both humans and tools. For
instance, PHPStorm will cross through any uses of a property marked
"@internal"; I wouldn't be surprised if other IDEs and tools can pick
this up as well.
In this case, you could just use the fact that the property is labelled
"@inject" to mark the distinction, and you'd be no worse off in terms of
tooling support than you are now (i.e. IDEs will not come with this
interpretation of "var" baked in anyway).
Regards,
Rowan Collins
[IMSoP]
"Rowan Collins" wrote in message news:56D42CD3.6020602@gmail.com...
Tony Marston wrote on 29/02/2016 09:55:
"James Titcumb" wrote in message
news:CAKnqCEY7art1GUWG=Pm0wyPGQmYp0Dq8oxdohgBkSGq+O_BTZw@mail.gmail.com...I see a difference in its
semantics. While thepublicmodifier states anyone can change the
property,varis useful for marking internal properties which must
be public, but should not be manipulated by simply anybodyIf it's public, it will be modified by someone.
Incorrect. It may be modified, but surely any invalid modifications
will be detected in the testing phase?Detected by whom? Using what tool?
If changing a variable directly instead of using a setter does not produce
an error that can be detected in your testing, whether that testing is
automated or manual, then is there actually an error? If doing something
does not cause a problem there there is no problem that needs fixing.
Preventing something from happening which does not cause an error even if it
did happen seems like wasted effort to me.
--
Tony Marston
Tony Marston wrote on 01/03/2016 09:32:
"Rowan Collins" wrote in message news:56D42CD3.6020602@gmail.com...
Tony Marston wrote on 29/02/2016 09:55:
"James Titcumb" wrote in message
news:CAKnqCEY7art1GUWG=Pm0wyPGQmYp0Dq8oxdohgBkSGq+O_BTZw@mail.gmail.com...Incorrect. It may be modified, but surely any invalid modifications
will be detected in the testing phase?Detected by whom? Using what tool?
If changing a variable directly instead of using a setter does not
produce an error that can be detected in your testing, whether that
testing is automated or manual, then is there actually an error? If
doing something does not cause a problem there there is no problem
that needs fixing. Preventing something from happening which does not
cause an error even if it did happen seems like wasted effort to me.
Firstly, no test suite can ever truly cover 100% of scenarios that the
live application will encounter, so the idea that a bug doesn't exist
until it causes an error is asking for trouble. You want to catch
mistakes as early as possible, and that is exactly what member
visibility is there for in the first place - to stop you in your tracks
if you try to access something that was supposed to be internal.
Secondly, violating visibility may have repercussions outside actual
errors. Consider something relying on accessing an "internal" property
and writing dozens of lines of code assuming it is of a particular type.
Then consider that the maintainer of the module which declared it
refactors and removes, renames, or changes the type of that property,
confident that they are safe to do so because it was for internal use
only. The result is much more wasted effort than keeping an eye out that
you're not violating visibility in the first place.
Regards,
Rowan Collins
[IMSoP]
Rowan Collins wrote on 01/03/2016 11:33:
Secondly, violating visibility may have repercussions outside actual
errors.
Incidentally, PHP itself encountered this a few years ago, where a
release of libxml2 changed internal behaviour that was being relied on
for a hack. The result was that entities like > started silently
disappearing from everyone's parsed XML if they compiled PHP against the
new library. See https://bugs.php.net/bug.php?id=45996 and
http://thread.gmane.org/gmane.comp.gnome.lib.xml.general/14610
Regards,
Rowan Collins
[IMSoP]
Rowan Collins wrote on 01/03/2016 11:33:
Secondly, violating visibility may have repercussions outside actual
errors.Incidentally, PHP itself encountered this a few years ago, where a
release of libxml2 changed internal behaviour that was being relied on
for a hack. The result was that entities like > started silently
disappearing from everyone's parsed XML if they compiled PHP against the
new library. See https://bugs.php.net/bug.php?id=45996 and
http://thread.gmane.org/gmane.comp.gnome.lib.xml.general/14610Regards,
The misuse of "var" as it was explained is reason alone to take action.
--
Richard "Fleshgrinder" Fussenegger
wrote in message news:56D5DDA6.4080607@fleshgrinder.com...
Rowan Collins wrote on 01/03/2016 11:33:
Secondly, violating visibility may have repercussions outside actual
errors.Incidentally, PHP itself encountered this a few years ago, where a
release of libxml2 changed internal behaviour that was being relied on
for a hack. The result was that entities like > started silently
disappearing from everyone's parsed XML if they compiled PHP against the
new library. See https://bugs.php.net/bug.php?id=45996 and
http://thread.gmane.org/gmane.comp.gnome.lib.xml.general/14610Regards,
The misuse of "var" as it was explained is reason alone to take action.
Just because one developer out of millions made a mistake is no reason to
punish those millions.
If "var" can be abused then "public" can be abused in the same way, so
surely the only way to avoid the possibility of ANY abuse whatsoever would
be to remove "public" as well as "var".
--
Tony Marston
Tony Marston wrote on 02/03/2016 09:53:
wrote in message news:56D5DDA6.4080607@fleshgrinder.com...
Rowan Collins wrote on 01/03/2016 11:33:
Secondly, violating visibility may have repercussions outside actual
errors.Incidentally, PHP itself encountered this a few years ago, where a
release of libxml2 changed internal behaviour that was being relied on
for a hack. The result was that entities like > started silently
disappearing from everyone's parsed XML if they compiled PHP against
the
new library. See https://bugs.php.net/bug.php?id=45996 and
http://thread.gmane.org/gmane.comp.gnome.lib.xml.general/14610Regards,
The misuse of "var" as it was explained is reason alone to take action.
Just because one developer out of millions made a mistake is no reason
to punish those millions.If "var" can be abused then "public" can be abused in the same way, so
surely the only way to avoid the possibility of ANY abuse whatsoever
would be to remove "public" as well as "var".
I think the point was that the difference between "var" and "public"
was being abused, which wouldn't be possible if there were only one keyword.
However, I agree that it's a very weak argument for removal (just as "I
[ab]use 'var' to mean something different from 'public'" is a weak
argument against removal).
Regards,
Rowan Collins
[IMSoP]
I think the point was that the difference between "var" and "public"
was being abused, which wouldn't be possible if there were only one
keyword.However, I agree that it's a very weak argument for removal (just as "I
[ab]use 'var' to mean something different from 'public'" is a weak
argument against removal).Regards,
It showcases what the studies about UI/UX found out about duplicated
behavior (or call it aliasing, multiple choices for the same thing, ...).
People are confused and we can and should avoid that.
The "var" keyword once emitted an E_STRICT but I guess it was turned off
again because too many people were complaining as they are now.
--
Richard "Fleshgrinder" Fussenegger
wrote in message news:56D73386.3000903@fleshgrinder.com...
I think the point was that the difference between "var" and "public"
was being abused, which wouldn't be possible if there were only one
keyword.However, I agree that it's a very weak argument for removal (just as "I
[ab]use 'var' to mean something different from 'public'" is a weak
argument against removal).Regards,
It showcases what the studies about UI/UX found out about duplicated
behavior (or call it aliasing, multiple choices for the same thing, ...).People are confused and we can and should avoid that.
Only some people are confused. But that confusion goes away once they RTFM
(Read The Friendly Manual).
If you want to avoid such confusion over alias names then surely that would
be an argument against introducing aliases in the first place. In this case
the short array syntax would never have been introduced as the (only
slightly longer) long array syntax had already existed since day #1.
The "var" keyword once emitted an
E_STRICTbut I guess it was turned off
again because too many people were complaining as they are now.
So if people are still using it then surely that is an argument AGAINST its
removal.
--
Tony Marston
The "var" keyword once emitted an
E_STRICTbut I guess it was turned off
again because too many people were complaining as they are now.So if people are still using it then surely that is an argument AGAINST
its removal.
The underlying problem here IS things like E_STRICT and E_DEPRECATED. On
one hand YES you can get legacy code working by hiding the warnings, but
that only makes the problem worse when someone actually completes the
cycle and removes the keyword. Getting code through the PHP5.2/3/4
cycles did require leaving all messages visible and handling each as
required. The problem with 'var' is that while one should probably
replace them all with public, there is a lot of simple legacy code still
in active use that could take years to 'tidy' and for no gain what so ever?
A quick scan of my current code base shows several thousand hits on 'var
' in both third party libraries, stock code and private stuff. Only a
small percentage are 'actually' replaceable by public but the time to go
through and manually check each one ... is it THAT much of a problem?
--
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
Lester,
The problem with 'var' is that while one should probably
replace them all with public, there is a lot of simple legacy code still
in active use that could take years to 'tidy'
'var' would not be removed until 8.x, so you'd have several years before
needing to make code changes. Additionally, the RFC will include this
script which automatically upgrades legacy code in mere seconds:
https://gist.github.com/colinodell/5fb5e5d474674f294a38
If you're staying on PHP 5.x or 7.0, no changes would be needed. If you're
upgrading to 7.1+, you would need to either hide deprecation notices or
take 30 seconds to run that script.
Only a small percentage are 'actually' replaceable by public
My understanding is that 'var' is simply an alias for 'public' so they
should behave identically. Could you please provide an example where 'var'
is not replaceable by 'public'?
Thanks for your feedback!
Colin O'Dell
Colin O'Dell wrote on 03/03/2016 12:47:
If you're staying on PHP 5.x or 7.0, no changes would be needed. If you're
upgrading to 7.1+, you would need to either hide deprecation notices or
take 30 seconds to run that script.
This isn't quite true. At the moment, PHP has no mechanism for hiding
notices within particular libraries, so if you're using a third-party
library, you have to either persuade the maintainer to put out a new
release, or maintain a fork, either of which may require significant effort.
My understanding is that 'var' is simply an alias for 'public' so they
should behave identically. Could you please provide an example where 'var'
is not replaceable by 'public'?
I'm not sure what Lester had in mind, but in many cases legacy code
which used "var" should actually be updated to mark properties as
"protected" or "private" instead. Such properties are public only
because PHP4 had no other visibility, and explicitly marking them all as
"public" simply masks the real job, which is assessing which visibility
each property should have.
It occurs to me that if I saw "var", I would not think "that should be
public", but "that needs assessing for visibility". I do the same with
legacy code where methods are written as "function foo()" rather than
"public function foo()" - I check whether it should actually be public,
and also in that case whether it should be static.
Regards,
Rowan Collins
[IMSoP]
Colin O'Dell wrote on 03/03/2016 12:47:
If you're staying on PHP 5.x or 7.0, no changes would be needed. If
you're
upgrading to 7.1+, you would need to either hide deprecation notices or
take 30 seconds to run that script.This isn't quite true. At the moment, PHP has no mechanism for hiding
notices within particular libraries, so if you're using a third-party
library, you have to either persuade the maintainer to put out a new
release, or maintain a fork, either of which may require significant
effort.
Additionally we ARE still having to maintain older versions of these
same libraries ...
My understanding is that 'var' is simply an alias for 'public' so they
should behave identically. Could you please provide an example where
'var'
is not replaceable by 'public'?I'm not sure what Lester had in mind, but in many cases legacy code
which used "var" should actually be updated to mark properties as
"protected" or "private" instead. Such properties are public only
because PHP4 had no other visibility, and explicitly marking them all as
"public" simply masks the real job, which is assessing which visibility
each property should have.It occurs to me that if I saw "var", I would not think "that should be
public", but "that needs assessing for visibility". I do the same with
legacy code where methods are written as "function foo()" rather than
"public function foo()" - I check whether it should actually be public,
and also in that case whether it should be static.
Actually my problem is even more simple than that - although it may be
possible to further filter the lookup for 'var ' ( note the space ) many
of the results are simply not text that needs changing. Many previous
changes have been possible simply with a global replaceand pick up the
odd mistake. var is simply not a candidate for that so while many
results can simply be skipped, each has to be reviewed and at that point
one may want to use something other than just public.
--
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
Lester Caine wrote on 03/03/2016 13:18:
Actually my problem is even more simple than that - although it may be
possible to further filter the lookup for 'var ' ( note the space ) many
of the results are simply not text that needs changing.
The script that Colin linked
(https://gist.github.com/colinodell/5fb5e5d474674f294a38) uses an
in-language tokenizer, not just text find-and-replace, so this is a
solved problem. If this turns out to not be smart enough, one built on
top of Nikita's PHP-Parser project would be pretty easy as well:
https://github.com/nikic/PHP-Parser/
Regards,
Rowan Collins
[IMSoP]
Actually my problem is even more simple than that - although it may be
possible to further filter the lookup for 'var ' ( note the space ) many
of the results are simply not text that needs changing.The script that Colin linked
(https://gist.github.com/colinodell/5fb5e5d474674f294a38) uses an
in-language tokenizer, not just text find-and-replace, so this is a
solved problem. If this turns out to not be smart enough, one built on
top of Nikita's PHP-Parser project would be pretty easy as well:
https://github.com/nikic/PHP-Parser/
My main reason for not taking that brute force approach is actually the
same. Many of the comment 'var' entries relate to the use of the
identified var. So changing one without the other just creates more
problems? It's the documentation style from 15 years ago that is just as
important to maintain and something that is not on the current roadmap?
The whole process needs addressing not just one element.
I've no problem that as code is tidied these elements get replaced and
that is already part of my own process. It's simply a matter of just how
'essential' it is that this is done, and I don't see any pressing need
as yet to remove var?
--
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
Lester Caine wrote on 04/03/2016 11:19:
My main reason for not taking that brute force approach is actually the
same. Many of the comment 'var' entries relate to the use of the
identified var. So changing one without the other just creates more
problems? It's the documentation style from 15 years ago that is just as
important to maintain and something that is not on the current roadmap?
The whole process needs addressing not just one element.
I'm not sure I follow. What do you mean by "comment 'var' entries"? To
my knowledge, /** @var ... */ is the correct notation for PHPDoc for a
property, whatever its visibility, but maybe you're talking about some
other comments?
I've no problem that as code is tidied these elements get replaced and
that is already part of my own process. It's simply a matter of just how
'essential' it is that this is done, and I don't see any pressing need
as yet to remove var?
This much I agree with. I see no urgency to batch update, even if the
cost of doing so is low.
Regards,
Rowan Collins
[IMSoP]
Lester Caine wrote on 04/03/2016 11:19:
My main reason for not taking that brute force approach is actually the
same. Many of the comment 'var' entries relate to the use of the
identified var. So changing one without the other just creates more
problems? It's the documentation style from 15 years ago that is just as
important to maintain and something that is not on the current roadmap?
The whole process needs addressing not just one element.I'm not sure I follow. What do you mean by "comment 'var' entries"? To
my knowledge, /** @var ... */ is the correct notation for PHPDoc for a
property, whatever its visibility, but maybe you're talking about some
other comments?
Where the variables are using in @var comments or in other comment
documentation, adding private or making other changes related to the
variable being changed ... cost of changing the 'var' may be low, but
then tidying up the documentation may have a higher time cost? One
really needs to address the whole picture for each change.
I've no problem that as code is tidied these elements get replaced and
that is already part of my own process. It's simply a matter of just how
'essential' it is that this is done, and I don't see any pressing need
as yet to remove var?This much I agree with. I see no urgency to batch update, even if the
cost of doing so is low.
Exactly :)
--
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
If you want to avoid such confusion over alias names then surely that
would be an argument against introducing aliases in the first place. In
this case the short array syntax would never have been introduced as the
(only slightly longer) long array syntax had already existed since day #1.
No, that is not what one should conclude from it. Short array syntax was
added by popular demand and hence for a very good reason. The fact that
there are no plans regarding the old syntax and thus keeping the
duplication indefinitely is the actual problem.
Change for the sake of change is bad, no argument there. Change for the
sake of progress is not and totally normal.
I'm not sure what Lester had in mind, but in many cases legacy code
which used "var" should actually be updated to mark properties as
"protected" or "private" instead. Such properties are public only
because PHP4 had no other visibility, and explicitly marking them all
"public" simply masks the real job, which is assessing which
visibility each property should have.It occurs to me that if I saw "var", I would not think "that should be
public", but "that needs assessing for visibility". I do the same with
legacy code where methods are written as "function foo()" rather than
"public function foo()" - I check whether it should actually be
public, and also in that case whether it should be static.
It seems as if this is not the issue for the people who are against
removing the "var" keyword from PHP 8. They simply do not want to change
their scripts at all. The described procedure is truly time consuming
since it involves to check all usages everywhere as well. Simply
changing from "var" or "public" to any other visibility is a brutal change.
--
Richard "Fleshgrinder" Fussenegger
Fleshgrinder wrote on 03/03/2016 16:53:
The fact that
there are no plans regarding the old syntax and thus keeping the
duplication indefinitely is the actual problem.
Having no plans to use something doesn't make it a problem. There still
needs to be some actual problem you are solving by removing it.
It occurs to me that if I saw "var", I would not think "that should be
public", but "that needs assessing for visibility". I do the same with
legacy code where methods are written as "function foo()" rather than
"public function foo()" - I check whether it should actually be
public, and also in that case whether it should be static.
It seems as if this is not the issue for the people who are against
removing the "var" keyword from PHP 8. They simply do not want to change
their scripts at all. The described procedure is truly time consuming
since it involves to check all usages everywhere as well. Simply
changing from "var" or "public" to any other visibility is a brutal change.
Let's not make generalisations about people's motives here. I am
expressing my reasoning for being against removal; others may have
other reasons, and you can discuss those with them.
My point was that bulk changing "var" to "public" is a
counter-productive change. It removes the information "this property's
visibility has not been reviewed", without actually adding any value.
This leaves us with a small gain (clearer to new users that the correct
keyword is "public"), and two small costs (the need to run a script over
all existing code to change "var" to "public", and the loss of
opportunity to manually review all instances of "var"); I'm not willing
to quantify those, but the balance doesn't feel in favour of change to me.
If there were some way of preventing users writing var in new code, I
would be all for it - there is no advantage to doing so, and it adds no
value to have two ways of writing "public". But there is no way for the
engine to distinguish new code from "legacy" code which already contains
the keyword. If someone can come up with a clean mechanism for doing
that (and in particular, for new code to say "I'm including this legacy
library which I will replace with modern code shortly, don't bother
telling me how many deprecated features it uses"), then I would be very
interested.
Regards,
Rowan Collins
[IMSoP]
Having no plans to use something doesn't make it a problem. There still
needs to be some actual problem you are solving by removing it.
I think in general that it would be helpful to have clear guidelines
regarding such topics. They would make deprecation discussions in
general simpler.
Let's not make generalisations about people's motives here. I am
expressing my reasoning for being against removal; others may have
other reasons, and you can discuss those with them.
:)
My point was that bulk changing "var" to "public" is a
counter-productive change. It removes the information "this property's
visibility has not been reviewed", without actually adding any value.
I understood your motivation and it is a very valid as well as honorable
one.
This leaves us with a small gain (clearer to new users that the correct
keyword is "public"), and two small costs (the need to run a script over
all existing code to change "var" to "public", and the loss of
opportunity to manually review all instances of "var"); I'm not willing
to quantify those, but the balance doesn't feel in favour of change to me.If there were some way of preventing users writing var in new code, I
would be all for it - there is no advantage to doing so, and it adds no
value to have two ways of writing "public". But there is no way for the
engine to distinguish new code from "legacy" code which already contains
the keyword. If someone can come up with a clean mechanism for doing
that (and in particular, for new code to say "I'm including this legacy
library which I will replace with modern code shortly, don't bother
telling me how many deprecated features it uses"), then I would be very
interested.
I always thought that E_STRICT is exactly that. I mean, an upgrade path
like ...
do nothing in PHP 5 (as is),
emit E_STRICT in PHP 7,
emit E_DEPRECATED in PHP 8,
remove in PHP 9
... would be fine with me too and go back to what I said initially: a
clear policy. Note that it would add several more years to the upgrade
path (6 years?).
Of course it is bad that people simply suppress those errors but that is
something that is completely out of control for us. People could easily
log them into a separate log as well during development and disable them
in production ...
Such a practice could also be easily applied to the RFC that proposes to
clean up many old inconsistent functions ...
do nothing in PHP 7,
emit E_STRICT in PHP 8,
emit E_DEPRECATED in PHP 9,
remove in PHP 10.
That results in around 9 years of time to adopt.
https://wiki.php.net/rfc/consistent_function_names
The biggest problem is when languages change to fast and for no real
benefit as we have seen it with many other languages and it almost
happened with PHP 6 (although the intention was good there).
--
Richard "Fleshgrinder" Fussenegger
Fleshgrinder wrote on 03/03/2016 17:32:
If there were some way of preventing users writing var innew code, I
would be all for it - there is no advantage to doing so, and it adds no
value to have two ways of writing "public". But there is no way for the
engine to distinguish new code from "legacy" code which already contains
the keyword. If someone can come up with a clean mechanism for doing
that (and in particular, for new code to say "I'm including this legacy
library which I will replace with modern code shortly, don't bother
telling me how many deprecated features it uses"), then I would be very
interested.
I always thought thatE_STRICTis exactly that. I mean, an upgrade path
like ...
There's a subtle distinction which I may not have explained very well.
What I want is the ability to selectively ignore these warnings. For
instance, if I write:
namespace \Foo\Bar\Baz;
class AwesomenessFactory implements ArrayAccess {
var $something;
}
... then I would be happy to see a notice that I'd used the wrong keyword.
But if I write:
TODO Replace dependency with modern equivalent
include 'Ancient/PEAR/Library.php';
... then I don't want to see 500 notices that the library I'm about to
replace has old-fashioned code in it. The same is true if I am actually
maintaining the included library, and have a rewrite in the works which
I am confident will supersede the current stable version long before the
next major version of PHP.
It's not about whether those notices are there for 6 years or 9 years,
or which E_* constant they appear under, it's about granularity of which
ones shout at me.
Regards,
Rowan Collins
[IMSoP]
There's a subtle distinction which I may not have explained very well.
What I want is the ability to selectively ignore these warnings. For
instance, if I write:namespace \Foo\Bar\Baz;
class AwesomenessFactory implements ArrayAccess {
var $something;
}... then I would be happy to see a notice that I'd used the wrong keyword.
But if I write:
TODO Replace dependency with modern equivalent
include 'Ancient/PEAR/Library.php';
... then I don't want to see 500 notices that the library I'm about to
replace has old-fashioned code in it. The same is true if I am actually
maintaining the included library, and have a rewrite in the works which
I am confident will supersede the current stable version long before the
next major version of PHP.It's not about whether those notices are there for 6 years or 9 years,
or which E_* constant they appear under, it's about granularity of which
ones shout at me.
The closest we have to achieve this is ignore_repeated_errors plus
ignore_repeated_source. However, you would still get one entry per
request/process/...
https://secure.php.net/errorfunc.configuration
--
Richard "Fleshgrinder" Fussenegger
wrote in message news:56D86C00.6000904@fleshgrinder.com...
If you want to avoid such confusion over alias names then surely that
would be an argument against introducing aliases in the first place. In
this case the short array syntax would never have been introduced as the
(only slightly longer) long array syntax had already existed since day
#1.No, that is not what one should conclude from it. Short array syntax was
added by popular demand
Really? Exactly how many of the millions of PHP developers out there voted
for this change?
and hence for a very good reason. The fact that
there are no plans regarding the old syntax and thus keeping the
duplication indefinitely is the actual problem.
Is it actually a "problem"? How many books and articles on PHP programming
are out there which use the "old" syntax? How much confusion would it cause
if the "old" and well known syntax were to be dropped? How many applications
would suddenly stop working? How much effort would be required in userland
to fix this state of affairs? How many swear words would these userland
developers have for the language developers? There are NO sideeffects of
leaving aliases in the language. It would take NO effort to leave them in,
but it would take effort to take them out which includes updating immense
volumes of documentation. The only "problem" is that it offends the delicate
sensibilities of a few "purist" developers who cannot understand the
difference between improving the language and breaking it.
Change for the sake of change is bad, no argument there. Change for the
sake of progress is not and totally normal.
Only if it results in an actual and measurable improvement. Changes for
"purity" or "consistency" do NOT fall into this category.
--
Tony Marston
wrote in message news:56D86C00.6000904@fleshgrinder.com...
If you want to avoid such confusion over alias names then surely that
would be an argument against introducing aliases in the first place. In
this case the short array syntax would never have been introduced as the
(only slightly longer) long array syntax had already existed since
day #1.No, that is not what one should conclude from it. Short array syntax was
added by popular demandReally? Exactly how many of the millions of PHP developers out there
voted for this change?
I was not part of the decision back then, however, it was how I received
the addition of the feature.
and hence for a very good reason. The fact that
there are no plans regarding the old syntax and thus keeping the
duplication indefinitely is the actual problem.Is it actually a "problem"? How many books and articles on PHP
programming are out there which use the "old" syntax? How much confusion
would it cause if the "old" and well known syntax were to be dropped?
How many applications would suddenly stop working? How much effort would
be required in userland to fix this state of affairs? How many swear
words would these userland developers have for the language developers?
There are NO sideeffects of leaving aliases in the language. It would
take NO effort to leave them in, but it would take effort to take them
out which includes updating immense volumes of documentation. The only
"problem" is that it offends the delicate sensibilities of a few
"purist" developers who cannot understand the difference between
improving the language and breaking it.
The argument in regards to books and articles is imho irrelevant. Nobody
learns Java 8 with a Java 2 book; nor do you learn PHP 8 with a PHP 4
book. This is just silly.
The upgrade path is important and not the fact that some 15+ year old
applications might not work anymore. Rowan Collins makes a much better
case here with his arguments instead of nagging at the stale argument of
"we need to support every line of (bad) code out there".
PHP being a mess is still one of the most quoted arguments against PHP!
Only if it results in an actual and measurable improvement. Changes for
"purity" or "consistency" do NOT fall into this category.
This is your believe and you know that many people disagrees with you on
this; you just commented on the "[RFC] Deprecations for PHP 7.1" thread
and we have much more of those RFCs and threads.
--
Richard "Fleshgrinder" Fussenegger
PHP being a mess is still one of the most quoted arguments against PHP!
Only if it results in an actual and measurable improvement. Changes for
"purity" or "consistency" do NOT fall into this category.
This is your believe and you know that many people disagrees with you on
this; you just commented on the "[RFC] Deprecations for PHP 7.1" thread
and we have much more of those RFCs and threads.
There are a number of schools of thought, one will say 'You don't have
to update your perfectly functional code', just use a version of PHP
that it will run on, so over 40% of users are 'stuck' with Php5.2/3
either because they don't have the support to change or the need to
change. Much of that code was written by people who are no longer
involved or interested and so unless others pick up the baton, there
will be little progress. I still run 5.2 on sites simply because it's
simply uneconomic to change them.
Now moving code forward, handling every warning and simply keeping code
running from version to version, one hits the problem that sites that
are reliant on older versions of PHP can't easily be run with newer
versions. I've managed to build a way around that problem by now running
php-fpm/nginx which allows me to actually run the same code across
multiple versions of PHP. But one has to be very careful about just what
is changed at each step, so in my book, unless there is some good
security reason to stop something working then it should remain for BC
reasons.
Others are of the opinion that all current PHP code is a mess and my
reaction to that is ... well use a different language then! ...
expecting the vast majority of users to rename every function ( on of
the proposals for PHP7 ) or switch to a strictly typed method of working
is simply not going to happen, so I have no problem with people adding
new extensions which allow these different sytles of working as long as
the underlying procedural style of working is maintained in as BC a way
as possible, so things like 'var' and a number of the 7.1 deprecation
proposals simply destroy BC with little gain to a pure OO based version
of PHP anyway.
I actually wonder what would have happened if there had been a stable
fork of PHP5.2 maintained, with security fixes, rather than the
piecemeal security fixes that are currently being applied on those
services that maintain PHP5.2/3 currently.
--
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
PHP being a mess is still one of the most quoted arguments against PHP!
Only if it results in an actual and measurable improvement. Changes for
"purity" or "consistency" do NOT fall into this category.This is your believe and you know that many people disagrees with you on
this; you just commented on the "[RFC] Deprecations for PHP 7.1" thread
and we have much more of those RFCs and threads.There are a number of schools of thought, one will say 'You don't have
to update your perfectly functional code', just use a version of PHP
that it will run on, so over 40% of users are 'stuck' with Php5.2/3
either because they don't have the support to change or the need to
change. Much of that code was written by people who are no longer
involved or interested and so unless others pick up the baton, there
will be little progress. I still run 5.2 on sites simply because it's
simply uneconomic to change them.Now moving code forward, handling every warning and simply keeping code
running from version to version, one hits the problem that sites that
are reliant on older versions of PHP can't easily be run with newer
versions. I've managed to build a way around that problem by now running
php-fpm/nginx which allows me to actually run the same code across
multiple versions of PHP. But one has to be very careful about just what
is changed at each step, so in my book, unless there is some good
security reason to stop something working then it should remain for BC
reasons.Others are of the opinion that all current PHP code is a mess and my
reaction to that is ... well use a different language then! ...
expecting the vast majority of users to rename every function ( on of
the proposals for PHP7 ) or switch to a strictly typed method of working
is simply not going to happen, so I have no problem with people adding
new extensions which allow these different sytles of working as long as
the underlying procedural style of working is maintained in as BC a way
as possible, so things like 'var' and a number of the 7.1 deprecation
proposals simply destroy BC with little gain to a pure OO based version
of PHP anyway.I actually wonder what would have happened if there had been a stable
fork of PHP5.2 maintained, with security fixes, rather than the
piecemeal security fixes that are currently being applied on those
services that maintain PHP5.2/3 currently.
But then again, we are talking about removal and real BC in 6 to 9 years
and support for code that is already roughly 11 years old; so up to 20
years old then. I guess nobody would ever consider rewriting that code
and instead simply write it anew.
--
Richard "Fleshgrinder" Fussenegger
PHP being a mess is still one of the most quoted arguments against PHP!
Only if it results in an actual and measurable improvement. Changes
for
"purity" or "consistency" do NOT fall into this category.This is your believe and you know that many people disagrees with you on
this; you just commented on the "[RFC] Deprecations for PHP 7.1" thread
and we have much more of those RFCs and threads.There are a number of schools of thought, one will say 'You don't have
to update your perfectly functional code', just use a version of PHP
that it will run on, so over 40% of users are 'stuck' with Php5.2/3
either because they don't have the support to change or the need to
change. Much of that code was written by people who are no longer
involved or interested and so unless others pick up the baton, there
will be little progress. I still run 5.2 on sites simply because it's
simply uneconomic to change them.Now moving code forward, handling every warning and simply keeping code
running from version to version, one hits the problem that sites that
are reliant on older versions of PHP can't easily be run with newer
versions. I've managed to build a way around that problem by now running
php-fpm/nginx which allows me to actually run the same code across
multiple versions of PHP. But one has to be very careful about just what
is changed at each step, so in my book, unless there is some good
security reason to stop something working then it should remain for BC
reasons.Others are of the opinion that all current PHP code is a mess and my
reaction to that is ... well use a different language then! ...
expecting the vast majority of users to rename every function ( on of
the proposals for PHP7 ) or switch to a strictly typed method of working
is simply not going to happen, so I have no problem with people adding
new extensions which allow these different sytles of working as long as
the underlying procedural style of working is maintained in as BC a way
as possible, so things like 'var' and a number of the 7.1 deprecation
proposals simply destroy BC with little gain to a pure OO based version
of PHP anyway.I actually wonder what would have happened if there had been a stable
fork of PHP5.2 maintained, with security fixes, rather than the
piecemeal security fixes that are currently being applied on those
services that maintain PHP5.2/3 currently.But then again, we are talking about removal and real BC in 6 to 9 years
and support for code that is already roughly 11 years old; so up to 20
years old then. I guess nobody would ever consider rewriting that code
and instead simply write it anew.--
Richard "Fleshgrinder" Fussenegger
For software written for other people and for projects that don't have
ongoing tech staffs that do tech debt maintenance, they would like to keep
old, working code running. Telling them that they must spend money to
update the software so that the language can look cleaning is often a hard
sell.
Outside of the PHP world, there are code bases that are 20-30 years old.
See Linux, Apache HTTPD, in-house software at many corporations.
One of the lessons of the Y2K rollover was that software choices made in
the 50-60's (and in some cases the actual software itself) was felt 40-50
years later because the software wasn't rewritten anew every 10-20 years.
Some companies treat software like capital assets and not as expendables.
They want it to last like a house and not be be replaced every 5-10 years
(like many cars).
Walter
--
The greatest dangers to liberty lurk in insidious encroachment by men of
zeal, well-meaning but without understanding. -- Justice Louis D. Brandeis
For software written for other people and for projects that don't have
ongoing tech staffs that do tech debt maintenance, they would like to keep
old, working code running. Telling them that they must spend money to
update the software so that the language can look cleaning is often a hard
sell.Outside of the PHP world, there are code bases that are 20-30 years old.
See Linux, Apache HTTPD, in-house software at many corporations.One of the lessons of the Y2K rollover was that software choices made in
the 50-60's (and in some cases the actual software itself) was felt 40-50
years later because the software wasn't rewritten anew every 10-20 years.
Some companies treat software like capital assets and not as expendables.
They want it to last like a house and not be be replaced every 5-10 years
(like many cars).Walter
That is correct; there are many, many old codebases of many different
languages out there. However, you need to consider in what way such
software is maintained. Let's start with Linux and Apache. Both of those
pieces of software are not in "maintenance" mode. They are both in
active development, and as such are living, changing codebases that are
being continually updated to have new features, bugfixes, and
compatibility with newer compilers, systems, and libraries.
Now consider some in-house software that is in maintenance only, as
there are also many of those. Assume one such software is written in C.
Let me ask you: are you going to compile such software with the latest
version of libc and using the C11 standard with the compiler? Of course
not! The likelihood of it compiling bug- and error-free is too common,
with functions removed in C11 and memory layouts changing in the last 30
years of libc. You would compile such a program with the appropriate
versions of its dependencies.
Now I'm not saying any of this is good or bad, I'm just saying it the
way it is. If you have 40+ year old software that you can't afford to
continually update, you should continue to use the best versions of
stuff that are still compatible. If you can afford to update small parts
to be compatible with newer systems, then do so. (I'm talking like
changing a few lines of code or maybe more to use a new function instead
of an old, deprecated one.)
In the PHP world (which is a tad bit different, since you can't ship
"binaries" compiled 10 years ago), the equivalent would be to run
10-year-old software on the best version of PHP that it is compatible
with; 5.6 (hopefully; maybe older, maybe newer -- depends on the
program). Now how long we backport security and bug fixes to old
versions is a completely different discussion, but I hope you get my
meaning.
--
Stephen
That is correct; there are many, many old codebases of many different
languages out there. However, you need to consider in what way such
software is maintained. Let's start with Linux and Apache. Both of those
pieces of software are not in "maintenance" mode. They are both in
active development, and as such are living, changing codebases that are
being continually updated to have new features, bugfixes, and
compatibility with newer compilers, systems, and libraries.Now consider some in-house software that is in maintenance only, as
there are also many of those. Assume one such software is written in C.
Let me ask you: are you going to compile such software with the latest
version of libc and using the C11 standard with the compiler? Of course
not! The likelihood of it compiling bug- and error-free is too common,
with functions removed in C11 and memory layouts changing in the last 30
years of libc. You would compile such a program with the appropriate
versions of its dependencies.Now I'm not saying any of this is good or bad, I'm just saying it the
way it is. If you have 40+ year old software that you can't afford to
continually update, you should continue to use the best versions of
stuff that are still compatible. If you can afford to update small parts
to be compatible with newer systems, then do so. (I'm talking like
changing a few lines of code or maybe more to use a new function instead
of an old, deprecated one.)In the PHP world (which is a tad bit different, since you can't ship
"binaries" compiled 10 years ago), the equivalent would be to run
10-year-old software on the best version of PHP that it is compatible
with; 5.6 (hopefully; maybe older, maybe newer -- depends on the
program). Now how long we backport security and bug fixes to old
versions is a completely different discussion, but I hope you get my
meaning.
This explanation matches my experience at companies as well. They either
use old systems (e.g. Windows XP is still in use at many companies in
Germany because there software was programmed against it) or old
software (Java 8 broke with Java 7, so did Java 7 with Java 6, so did
...) and they simply do not bother to update at all. Not the code, not
the system, nor the software.
@Tony Marston: you are always saying that "this is "longevity" [...]
they will move on to another language" but I do not see such a language,
not a single one. There are those who break with every release
(node.js), those who break hard with a major release (Python), and those
who are carefully crafted to contain proper CHANGELOGs, upgrade paths,
deprecations, ... (Java, C derivatives) and then there is PHP where it
is completely random based on the people who saw the actual thread on
the mailing list and shouted the loudest.
Removing old or bad features is absolutely normal and it is what is
being done in good languages. You want to keep your interfaces clean and
easy to understand. You do not want them to be cluttered with
unnecessary features, aliases, argument swapping, ...
Expecting to write some code without any kind of maintenance while
expecting the systems and software to ensure it runs for the next
decades without any kind of issues is naive.
--
Richard "Fleshgrinder" Fussenegger
wrote in message news:56DBFDB5.1010806@fleshgrinder.com...
<snip>
@Tony Marston: you are always saying that "this is "longevity" [...]
they will move on to another language" but I do not see such a language,
not a single one. There are those who break with every release
(node.js), those who break hard with a major release (Python), and those
who are carefully crafted to contain proper CHANGELOGs, upgrade paths,
deprecations, ... (Java, C derivatives) and then there is PHP where it
is completely random based on the people who saw the actual thread on
the mailing list and shouted the loudest.
Just because YOU have not encountered such languages does not mean that they
do not exist. Before using PHP I used two other languages for over a decade
each, and both of them went through several upgrades which added new
functionality WITHOUT breaking existing functionality. That takes brains and
discipline, something which appears to be lacking in the PHP community.
Some of us write enterprise software which is expected to last for a long
time, not toy websites which are built with the expectation "use once then
throw away and start again". Enterprise applications have very large code
bases, and it would be a VERY expensive and time consuming exercise to
perform a major rewrite with every major release of the language.
I do not mind new features being added to the language provided that I am
not forced to use them. I do not mind old features being removed because of
genuine security issues. But I DO mind having to refactor my code just
because some numpty decides to remove a long-standing feature just because
it does not fit in with today's fashion. Excuses such as "it's redundant" or
"it's inconsistent" or "I don't use it, and I don't think that anyone else
should use it" are unacceptable.
Leaving old features alone does not cost anything. Taking them out will take
effort, both in changing the code and updating the documentation as well as
the ENORMOUS effort required in userland to update their software. This will
achieve nothing except to piss a lot of people off.
Removing old or bad features is absolutely normal
Bad features, Yes. Old features, No.
and it is what is
being done in good languages.
That depends on your definition of a "good" language. If you look at the
language statistics you will see that PHP, with all its quirks, has been in
the top ten for a very long time. Changing it now will not be an improvement
to many programmers, it will be a disaster and a reason not to upgrade.
You want to keep your interfaces clean and
easy to understand. You do not want them to be cluttered with
unnecessary features, aliases, argument swapping, ...
Competent programmers have managed with the quirks in PHP for decades, just
like they have managed with the quirks which exist in every other language.
Expecting to write some code without any kind of maintenance while
expecting the systems and software to ensure it runs for the next
decades without any kind of issues is naive.
No it is not. This was the standard for all the other languages I used
before PHP. Mind you, those languages were maintained by groups of competent
professionals and not an army of chimpanzees.
--
Tony Marston
Tony Marston wrote on 07/03/2016 09:14:
That takes brains and discipline, something which appears to be
lacking in the PHP community.
[...]
just because some numpty decides
[...]
groups of competent professionals and not an army of chimpanzees.
Please try to refrain from personal insults.
I haven't read the last few messages in this sub-thread, so to be clear,
this applies equally to everyone, and is in no way a comment on who is
"right".
Whatever the provocation, there is always a choice available to resist
emotional responses, and re-focus the discussion onto technical issues,
or just summarise your position in neutral terms and agree to disagree.
Regards,
Rowan Collins
[IMSoP]
a
"Rowan Collins" wrote in message news:56DD64F5.5010503@gmail.com...
Tony Marston wrote on 07/03/2016 09:14:
That takes brains and discipline, something which appears to be lacking
in the PHP community.
[...]
just because some numpty decides
[...]
groups of competent professionals and not an army of chimpanzees.Please try to refrain from personal insults.
That was not a personal insult as it was not aimed at an individual person.
I was borrowing from the saying that "if you put a million typewriters in
front of a million chimpanzees they will eventually produce the works of
Shakespeare"
I haven't read the last few messages in this sub-thread, so to be clear,
this applies equally to everyone, and is in no way a comment on who is
"right".Whatever the provocation, there is always a choice available to resist
emotional responses, and re-focus the discussion onto technical issues, or
just summarise your position in neutral terms and agree to disagree.Regards,
--
Tony Marston
Tony Marston wrote on 08/03/2016 09:51:
a
"Rowan Collins" wrote in message news:56DD64F5.5010503@gmail.com...Tony Marston wrote on 07/03/2016 09:14:
That takes brains and discipline, something which appears to be
lacking in the PHP community.
[...]
just because some numpty decides
[...]
groups of competent professionals and not an army of chimpanzees.Please try to refrain from personal insults.
That was not a personal insult as it was not aimed at an individual
person. I was borrowing from the saying that "if you put a million
typewriters in front of a million chimpanzees they will eventually
produce the works of Shakespeare"
Regardless of the exact definition of "insult", you are repeatedly
questioning people's competence, professionalism, and intelligence; this
is not a productive approach to a debate. So again, I would invite you -
and others on this thread - to step back and put the emotion to one side.
Clearly, there is a difference of opinion, and that difference probably
isn't going to go away by repeating the same points in different words,
so let's try to think of productive ways forward.
You have mentioned stability as a good aim, and have given the examples
of COBOL and UNIFACE which we might learn something from; Richard has
mentioned that lack of consistency being a frequent criticism of PHP. Is
there some way we can formulate a policy, based on experience elsewhere,
of how to balance those two aims?
Regards,
Rowan Collins
[IMSoP]
"Rowan Collins" wrote in message news:56DEA829.5030903@gmail.com...
Tony Marston wrote on 08/03/2016 09:51:
a
"Rowan Collins" wrote in message news:56DD64F5.5010503@gmail.com...Tony Marston wrote on 07/03/2016 09:14:
That takes brains and discipline, something which appears to be lacking
in the PHP community.
[...]
just because some numpty decides
[...]
groups of competent professionals and not an army of chimpanzees.Please try to refrain from personal insults.
That was not a personal insult as it was not aimed at an individual
person. I was borrowing from the saying that "if you put a million
typewriters in front of a million chimpanzees they will eventually
produce the works of Shakespeare"Regardless of the exact definition of "insult", you are repeatedly
questioning people's competence, professionalism, and intelligence;
If you read those "insults", which were pretty mild as insults go, you
should see that none of them was aimed at a single person, so cannot be
described as "personal".
Those who advocate the removal of long-standing features of the language FOR
NO GOOD REASON, thus causing BC breaks which cause havoc to the millions of
userland developers, need to have their competence, professionalism, and
intelligence questioned. Forcing their personal preferences onto the entire
PHP community and breaking countless numbers of applications FOR NO GOOD
REASON is something to be frowned upon and avoided.
this is not a productive approach to a debate. So again, I would invite
you - and others on this thread - to step back and put the emotion to one
side.Clearly, there is a difference of opinion, and that difference probably
isn't going to go away by repeating the same points in different words, so
let's try to think of productive ways forward.You have mentioned stability as a good aim, and have given the examples of
COBOL and UNIFACE which we might learn something from; Richard has
mentioned that lack of consistency being a frequent criticism of PHP. Is
there some way we can formulate a policy, based on experience elsewhere, of
how to balance those two aims?
Every language I have ever worked with has had its fair share of quirks and
inconsistences, but competent developers learn to live with them. Besides,
lack of "consistency" is very hard to measure as it is purely subjective and
not objective. You have to first identify with what you are trying to be
consistent, and then to what level.
You could say that having function names which don't start with the letter
"B" are inconsistent.
You could say that having function names which don't all have 13 letters are
inconsistent.
You could say that having function names which don't all start with a verb
are inconsistent.
You first have to define what is "consistent" and what is not, and that will
be a difficult exercise as different people will have different opinions,
just as there is agreed definition of "perfect" and "pure" and "best".
I think that the PHP language developers should have a policy that no
feature or function can be removed from the language UNLESS it is proven to
cause either security or performance issues. They can add new features for
whatever reason without forcing me to use them, but they should leave all
existing features alone. There is a difference between improving the
language and destroying it.
Anyone who does not like the way that PHP works should be told to switch to
a language that they DO like. The millions of developers who have been using
the language for the past decade or so and who have made PHP the #1 language
for the internet DO NOT LIKE their language being broken.
--
Tony Marston
need to have their competence, professionalism, and intelligence
questioned.
Tony, making a statement like this is unprofessional in itself. You've
already been asked to put emotions aside and discuss this topic on the
technical merit, there's no need to question people's competence,
professionalism, and intelligence.
Please - can we all discuss this in a nice way, without insults,
questioning intelligence, attacks, etc.
Anyone who does not like the way that PHP works should be told to switch to
a language that they DO like. The millions of developers who have been
using the language for the past decade or so and who have made PHP the #1
language for the internet DO NOT LIKE their language being broken.
At risk of fighting fire with fire, the same could be said to you - if you
don't like the language evolving and changing, switch to a language whose
proposed modifications doesn't offend you so greatly...
It's a trivial task to replace var with public, and if I had any voting
karma, I'd vote +1 to remove var, based on the fact the intent of
public is much clearer than var. If the change is well documented (and
things like this usually are in my experience of PHP), then I don't see an
issue. No-one will force anyone to upgrade to PHP 8 or 9 (whenever this
change would be targeted for), you could happily continue using PHP 4 if
you like, as others have pointed out.
"James Titcumb" wrote in message
news:CAKnqCEZMh-P8XmAeQtdPnw4ZaZGb4=wmm_9QYZPhtuPUwaXLCA@mail.gmail.com...
need to have their competence, professionalism, and intelligence
questioned.Tony, making a statement like this is unprofessional in itself. You've
already been asked to put emotions aside and discuss this topic on the
technical merit,
There is no technical reason why "var" should be removed. Is there a
security issue? No. Is there a performance issue? No. It is just a matter of
one small group of people trying to impose their personal preferences on the
rest of the PHP community.
there's no need to question people's competence,
professionalism, and intelligence.
It is perfectly legitimate to question the competence, professionalism, and
intelligence of any individual (or group) who seeks to break BC for NO GOOD
REASON other than personal preference.
Please - can we all discuss this in a nice way, without insults,
questioning intelligence, attacks, etc.Anyone who does not like the way that PHP works should be told to switch to
a language that they DO like. The millions of developers who have been
using the language for the past decade or so and who have made PHP the #1
language for the internet DO NOT LIKE their language being broken.At risk of fighting fire with fire, the same could be said to you - if you
don't like the language evolving and changing switch to a language whose
proposed modifications doesn't offend you so greatly...
I don't mind a language that evolves with the addition of new features
provided that I am not forced to use them. What I, and huge numbers of other
developers, DO mind is to have code which worked perfectly with the
previous version suddenly break with the new version FOR NO GOOD REASON.
It's a trivial task to replace
varwithpublic, and if I had any voting
karma, I'd vote +1 to removevar, based on the fact the intent of
publicis much clearer thanvar. If the change is well documented (and
things like this usually are in my experience of PHP), then I don't see an
issue. No-one will force anyone to upgrade to PHP 8 or 9 (whenever this
change would be targeted for), you could happily continue using PHP 4 if
you like, as others have pointed out.
I am NOT still using PHP 4. I do, however, have a large amount of code that
was written for PHP 4 which has run perfectly well through all versions of
PHP 5 up to the latest 5.6 version. Like most developers in the real world I
expect valid code that runs in version X to still run in version X+1. The
only reason to change existing code would be to take advantage of a new
feature. Being forced to change code because some inconsiderate and
self-centered group of individuals has unilaterally decided that a perfectly
valid function or feature is no longer fashionable is something that makes
me very angry because I have to spend valuable amounts of my time to do
something which should not be necessary.
Language developers who are incapable of introducing new features without
breaking old ones do not deserve to be regarded as either professional,
competent or intelligent.
"Improving" the language should NOT involve rewriting it to conform to
today's fashion or fad. Introducing BC breaks for NO GOOD REASON should be
outlawed.
If a language cannot offer stability and longevity then organisations are
going to think twice before investing large amounts of manpower in using it
to write applications which are expected to last 10, 15 or even 20 years.
Saying that I don't actually have to upgrade is a stupid remark to make. A
huge number of web applications are run on hosted servers, and those hosting
services like to keep up-to-date with the latest PHP version. They are only
prevented from doing so because their customers have applications that are
broken with the latest version. This is why it took such a long time for PHP
5 to be adopted. This is why there are significant numbers of hosts still
running 5.2 or 5.3. This is why I fully expect the take-up of PHP 7 to be
very slow. Take up would be much faster if only you un-clever not-first-rate
meddlers would stop breaking the language for NO GOOD REASON.
--
Tony Marston
It is perfectly legitimate to question the competence, professionalism,
and intelligence of any individual (or group) who seeks to break BC for NO
GOOD REASON other than personal preference.
As has already stated, you are insulting people by doing this. Please stop
insulting people; as far as I was aware, this is a place for technical
discussion, not playground insults and essentially calling everyone who
disagrees with you as essentially dumb.
if only you un-clever not-first-rate meddlers would stop breaking the
language for NO GOOD REASON.
Language developers who are incapable of introducing new features without
breaking old ones do not deserve to be regarded as either professional,
competent or intelligent.
Saying that I don't actually have to upgrade is a stupid remark to make.
some inconsiderate and self-centered group of individuals
Please stop with the insults. The integrity of your argument (which you've
stated repeatedly, using plenty of capital letters - we get the point, you
don't want this change, because you are of the opinion that BC breaks are
unacceptable) is totally undermined by resorting to insults and bullying.
You are one voice, and you have been heard loud and clear. Speak only for
yourself, and not everyone - don't assume that most developers all agree
with you. Let them speak, and preferably without insulting them in the
process.
My opinion is that the RFC is proposed (as this discussion is going
nowhere, fast), and we discuss this like adults (without resulting to
insulting each other), and ultimately put it to vote. If "var" is kept,
then so be it. If "var" is deprecated, then so be it.
"James Titcumb" wrote in message
news:CAKnqCEZMh-P8XmAeQtdPnw4ZaZGb4=wmm_9QYZPhtuPUwaXLCA@mail.gmail.com...need to have their competence, professionalism, and intelligence
questioned.Tony, making a statement like this is unprofessional in itself. You've
already been asked to put emotions aside and discuss this topic on the
technical merit,
- rant content *
All that may be true for a language, that was designed in the first place.
PHP had a different path, one that made it grow organically and with lots
of mistakes, inconsistencies and other problems. All that means that any
effort to clean up the language and engine are going to break a lot of old
code whatever you do to the language. Heck, before PHP7 there where
limitations to the language parser that just prevented quite a few good and
sizeable rfc's from being implemented.
And as I said previously, var is actually missing functionality to be an
alias of public. They are not the same functionality wise. Var cannot
replace public in all cases.
I mean, I have 2 10-12 years old projects (no one actually knows how old
they are, just that it's 10+), that I do support. And that support includes
actually fixing a lot of problems, much more serious and impactfull than
"var". I'm running them on 5.6 in E_ALL mode, going to move to PHP 7 in
coming month or two.
You either maintain it, or you just get stuck on old PHP versions, that's
it. I did migrate them from 5.2 to 5.6 in one go - that was my first task
when I got them. And that doubled the performance too. The amount of stuff
that was dropped and changed in between these versions is huge, and still,
it was not hard at all. Mostly mondain stuff. So I perfectly do know the
hardships of legacy software in PHP - hype is overrated.
I have the opinion that the more hard the project is to support, the lazier
the developers that work on it are/were.
Le jeudi 10 mars 2016, 10:28:58 Tony Marston a écrit :
It is perfectly legitimate to question the competence, professionalism, and
intelligence of any individual (or group) who seeks to break BC for NO GOOD
REASON other than personal preference.
I don't mind a language that evolves with the addition of new features
provided that I am not forced to use them. What I, and huge numbers of other
developers, DO mind is to have code which worked perfectly with the
previous version suddenly break with the new version FOR NO GOOD REASON.
"Improving" the language should NOT involve rewriting it to conform to
today's fashion or fad. Introducing BC breaks for NO GOOD REASON should be
outlawed.
This is why I fully expect the take-up of PHP 7 to be
very slow. Take up would be much faster if only you un-clever not-first-rate
meddlers would stop breaking the language for NO GOOD REASON.
Oh, it’s okay then, because we want to remove the var keyword FOR A GOOD REASON, so we should be fine.
Note that I’m not sure who this «we» is, I’m using «we» because you said «you», but I had nothing to do with PHP7 BC breaks. (Which are mostly a good think, BTW)
Tony Marston wrote on 10/03/2016 10:28:
some inconsiderate and self-centered group of individuals has
unilaterally decided
There is no conspiracy. You are contributing to the list where the
decisions are made. If you think the decision-making process can be
improved, help us improve it. If you want to participate in the existing
process, participate (and if you want to understand more about how it
works, ask). If you don't want to do either of those things, I'm not
sure what you expect us to do with your messages.
Regards,
Rowan Collins
[IMSoP]
as @Arvids said, var is missing functionality that public has, so they are
not exact aliases of each other. i think this is valid enough reason to
remove it.
even if it weren't the case, I would say let the language maintainers
decide if this cleanup would be worth it to them and make their lives
easier and their code more consistent, and userland developers (including
myself) be damned in 5+ years with this minor inconvenience. I think 5
years is plenty of lead time to make this fix.
I'm with @James. I'm getting sick of listening to the same argument over
and over. Put it to a vote, and accept whatever happens.
--
Andrew Brown
All languages are evolving, and part of that is removing old baggage, even
if that baggage is harmful. Because ease of maintenance. When you have
multiple ways to do a thing, that means that when you touch some part of
it, you have to remember to update everything else. It's easy with
functions/methods, because aliasing is essentially forwarding the call. But
with the language grammar that means modifying the parser for the language
in multiple places and not necessarily as a copy/paste of the changed rules.
The argument, that it's there for ages is not a good technical argument why
not to remove it.
And by the way, there is an actual case, that var can't cover, but
public/private/protected does.
You can't do this:
class Blah {
var static $a = 0;
}
but this obviously works
class Blah {
public static $a = 0;
}
So, "var" is not the same as "public", it's a subset of "public"
functionality actually. And I just checked the docs -it's not mentioned in
the docs anywhere.
And this is precisely why with time you need to remove the old baggage and
duplicate functionality. We can give people ample time to update libraries,
because removing "var" is not going to happen until PHP8 for sure, that's
probably at least 5-7 years, and deprecation warnings are easy to deal with.
Yes. we need to keep BC in mind, but this particular issue is trivially
easy to fix, even automated tools are provided, cleans up an inconsistency
between var and public, frees up "var" keyword for future usage for more
advanced concepts and just removes the duplication of functionality.
BC for the sake of BC is just silly.
Arvids.
Hi all,
Keeping aliases do not harm much. It may stay forever.
How about stop discussion, but write code?
The only chance this kind of proposal to pass is existence of
"conversion program" that replaces aliases in older codes.
If there is anyone who would like to volunteer for this, please write
generic code that can replace function/method/class/keyword aliases
perfectly. i.e. Write program that understands PHP syntax and replaces
targets precisely, not "perl pi.bak -e 's/obsolete_name/new_name/g'
*.php. This program would be very useful for us to clean various
things up.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Yasuo Ohgaki wrote on 09/03/2016 10:35:
Hi all,
Keeping aliases do not harm much. It may stay forever.
How about stop discussion, but write code?
The only chance this kind of proposal to pass is existence of
"conversion program" that replaces aliases in older codes.If there is anyone who would like to volunteer for this, please write
generic code that can replace function/method/class/keyword aliases
perfectly. i.e. Write program that understands PHP syntax and replaces
targets precisely, not "perl pi.bak -e 's/obsolete_name/new_name/g'
*.php. This program would be very useful for us to clean various
things up.
Somebody already posted this quick solution, using PHP's built-in
tokenizer: https://gist.github.com/colinodell/5fb5e5d474674f294a38
I don't know if there are any edge-cases it doesn't cater for, or
undesirable side-effects, but it's certainly smarter than just a Perl
regex. There are also examples for making code modification in the docs
for Nikita's PHP-Parser library: https://github.com/nikic/PHP-Parser/
Regards,
Rowan Collins
[IMSoP]
@Tony Marston: I cannot reply anymore to you because you are
discrediting yourself with every mail you send and I do not want to
contribute to this any further; I might reply again if you write
something that is actually contributing to this discussion. In the
meantime: read what Rowan Collins wrote. :)
If this cleanup is such a good idea, why did it take 12 years for
someone to suggest it. Why wasn't var removed years ago? What is the
sudden urgency to remove it now?
It was already emitting an E_STRICT in the past but that was removed
again. I cannot tell why there is no policy regarding such topics but
now it just came up. Also note, removal could have happened with PHP 7
the earliest. This chance was missed due to more important topics.
Have programmer become more confused? This alias does not appear to
have been an issue for the last 12 years.
Nope, of course not. That was just one of several arguments why the
removal should happen in the future.
What has changed? Are we on a cusp of the paradigm change (the type
that happens when the old folk have gone away, so the younger folk
can get their way because they now have the numbers)?
Maybe, or maybe some people simply take the major criticism of their
favorite language seriously and see it as constructive input to improve it.
All languages are evolving, and part of that is removing old baggage, even
if that baggage is harmful. Because ease of maintenance. When you have
multiple ways to do a thing, that means that when you touch some part of
it, you have to remember to update everything else. It's easy with
functions/methods, because aliasing is essentially forwarding the call. But
with the language grammar that means modifying the parser for the language
in multiple places and not necessarily as a copy/paste of the changed rules.
The argument, that it's there for ages is not a good technical argument why
not to remove it.And by the way, there is an actual case, that var can't cover, but
public/private/protected does.
You can't do this:
class Blah {
var static $a = 0;
}but this obviously works
class Blah {
public static $a = 0;
}So, "var" is not the same as "public", it's a subset of "public"
functionality actually. And I just checked the docs -it's not mentioned in
the docs anywhere.And this is precisely why with time you need to remove the old baggage and
duplicate functionality. We can give people ample time to update libraries,
because removing "var" is not going to happen until PHP8 for sure, that's
probably at least 5-7 years, and deprecation warnings are easy to deal with.
Yes. we need to keep BC in mind, but this particular issue is trivially
easy to fix, even automated tools are provided, cleans up an inconsistency
between var and public, frees up "var" keyword for future usage for more
advanced concepts and just removes the duplication of functionality.
BC for the sake of BC is just silly.Arvids.
:)
--
Richard "Fleshgrinder" Fussenegger
Hi list,
I think that removing it in any 7.x would be too soon. We should mark it as
future deprecation then remove it at a later date. While I don't come
across the use of var too much, it does still exist in code bases that are
quite old.
@Tony Marston: I cannot reply anymore to you because you are
discrediting yourself with every mail you send and I do not want to
contribute to this any further; I might reply again if you write
something that is actually contributing to this discussion. In the
meantime: read what Rowan Collins wrote. :)If this cleanup is such a good idea, why did it take 12 years for
someone to suggest it. Why wasn't var removed years ago? What is the
sudden urgency to remove it now?It was already emitting an
E_STRICTin the past but that was removed
again. I cannot tell why there is no policy regarding such topics but
now it just came up. Also note, removal could have happened with PHP 7
the earliest. This chance was missed due to more important topics.Have programmer become more confused? This alias does not appear to
have been an issue for the last 12 years.Nope, of course not. That was just one of several arguments why the
removal should happen in the future.What has changed? Are we on a cusp of the paradigm change (the type
that happens when the old folk have gone away, so the younger folk
can get their way because they now have the numbers)?Maybe, or maybe some people simply take the major criticism of their
favorite language seriously and see it as constructive input to improve it.All languages are evolving, and part of that is removing old baggage,
even
if that baggage is harmful. Because ease of maintenance. When you have
multiple ways to do a thing, that means that when you touch some part of
it, you have to remember to update everything else. It's easy with
functions/methods, because aliasing is essentially forwarding the call.
But
with the language grammar that means modifying the parser for the
language
in multiple places and not necessarily as a copy/paste of the changed
rules.
The argument, that it's there for ages is not a good technical argument
why
not to remove it.And by the way, there is an actual case, that var can't cover, but
public/private/protected does.
You can't do this:
class Blah {
var static $a = 0;
}but this obviously works
class Blah {
public static $a = 0;
}So, "var" is not the same as "public", it's a subset of "public"
functionality actually. And I just checked the docs -it's not mentioned
in
the docs anywhere.And this is precisely why with time you need to remove the old baggage
and
duplicate functionality. We can give people ample time to update
libraries,
because removing "var" is not going to happen until PHP8 for sure, that's
probably at least 5-7 years, and deprecation warnings are easy to deal
with.
Yes. we need to keep BC in mind, but this particular issue is trivially
easy to fix, even automated tools are provided, cleans up an
inconsistency
between var and public, frees up "var" keyword for future usage for more
advanced concepts and just removes the duplication of functionality.
BC for the sake of BC is just silly.Arvids.
:)
--
Richard "Fleshgrinder" Fussenegger
"Arvids Godjuks" wrote in message
news:CAL0xaBF-cx+hijFD=YNiihhKknpxwo0JdO+oNRada=B0jyyz7A@mail.gmail.com...
All languages are evolving, and part of that is removing old baggage, even
if that baggage is harmful. Because ease of maintenance. When you have
multiple ways to do a thing, that means that when you touch some part of
it, you have to remember to update everything else. It's easy with
functions/methods, because aliasing is essentially forwarding the call. But
with the language grammar that means modifying the parser for the language
in multiple places and not necessarily as a copy/paste of the changed
rules.
The argument, that it's there for ages is not a good technical argument why
not to remove it.And by the way, there is an actual case, that var can't cover, but
public/private/protected does.
You can't do this:
class Blah {
var static $a = 0;
}but this obviously works
class Blah {
public static $a = 0;
}So, "var" is not the same as "public", it's a subset of "public"
functionality actually. And I just checked the docs -it's not mentioned in
the docs anywhere.And this is precisely why with time you need to remove the old baggage and
duplicate functionality.
I disagree. There is NO need to remove duplicate functionality. There is
NO need to remove functionality just because it is old or unfashionable.
We can give people ample time to update libraries,
because removing "var" is not going to happen until PHP8 for sure, that's
probably at least 5-7 years, and deprecation warnings are easy to deal
with.
Yes. we need to keep BC in mind, but this particular issue is trivially
easy to fix, even automated tools are provided, cleans up an inconsistency
between var and public, frees up "var" keyword for future usage for more
advanced concepts and just removes the duplication of functionality.
BC for the sake of BC is just silly.
It does not matter how easy you think the fix is, it would still place a
huge burden on the application developers before they could take advantage
of any improvements in the new version.
--
Tony Marston
Tony Marston wrote on 09/03/2016 09:51:
Those who advocate the removal of long-standing features of the
language FOR NO GOOD REASON [...]
What you have to understand is that this is YOUR OPINION. Even if, in
your opinion, anyone who doesn't share that opinion is incompetent, or
whatever word you choose, it doesn't really help anyone to keep saying so.
One other point, you are talking about those managing the language as
"they", but it should be "we" - by actively participating in this list,
YOU are part of the group steering the language, just as much as any of
the people talking on this thread.
You first have to define what is "consistent" and what is not, and
that will be a difficult exercise as different people will have
different opinions, just as there is agreed definition of "perfect"
and "pure" and "best".
This is true, but I don't think "perfect" needs to be the aim; we can
come up with ideas that have a rough consensus [1] about what we'd like
the language to look like, and what it's practical to change. For
instance, do we want the language to be more Perl like (lots of
overlapping features, TMTOWTDI) or more "opinionated" (with an explicit
"right" way to do things)?
I think that the PHP language developers should have a policy that no
feature or function can be removed from the language UNLESS it is
proven to cause either security or performance issues. They can add
new features for whatever reason without forcing me to use them, but
they should leave all existing features alone.
That seems like a reasonable start, but there are problems with such a
blanket prohibition: some new features require old code to be broken in
order to be implemented, and any change can break something that someone
was relying on [https://xkcd.com/1172/] so you need some definition of
"existing feature".
Anyone who does not like the way that PHP works should be told to
switch to a language that they DO like.
Just a quick point that here, too, you can include yourself - if you
think PHP is such a badly-run language, you are free to use a different
one. Clearly, though, there are some things you like about it, which is
why you're here, one of us, trying to make it better.
[1] Somebody linked a while ago to this RFC, which I admit I haven't
fully read, about "rough consensus". https://tools.ietf.org/html/rfc7282
Regards,
Rowan Collins
[IMSoP]
wrote in message news:56DAF480.7030508@fleshgrinder.com...
PHP being a mess is still one of the most quoted arguments against PHP!
But then again, we are talking about removal and real BC in 6 to 9 years
and support for code that is already roughly 11 years old; so up to 20
years old then. I guess nobody would ever consider rewriting that code
and instead simply write it anew.
I will never accept any BC breaks unless it is to solve a genuine security
issue. Saying that it's only going to happen in 6 to 9 years is irrelevant
as it should never happen at all. Saying that code which is 11 years old
should be rewritten is just plain naive. If a language cannot support code
that was written 11 years then that language will be regarded as unstable in
the real world.
One of the most successful pieces of software is an ERP application from SAP
which was started in 1970, and it is still going. Why? Do the maintainers of
that software keep rewriting it every 5 years to keep up with the latest
programming fashion? The answer is "NO". They cannot afford to rewrite their
application every 5 years, and their customers would hate to go through an
expensive upgrade every 5 years. The customers expect longevity and
stability. What you are trying to do to PHP would destroy that, and for NO
GOOD REASON!
--
Tony Marston
"Lester Caine" wrote in message news:56DAE00F.2030203@lsces.co.uk...
PHP being a mess is still one of the most quoted arguments against PHP!
Only if it results in an actual and measurable improvement. Changes
for
"purity" or "consistency" do NOT fall into this category.This is your believe and you know that many people disagrees with you on
this; you just commented on the "[RFC] Deprecations for PHP 7.1" thread
and we have much more of those RFCs and threads.There are a number of schools of thought, one will say 'You don't have
to update your perfectly functional code', just use a version of PHP
that it will run on, so over 40% of users are 'stuck' with Php5.2/3
either because they don't have the support to change or the need to
change. Much of that code was written by people who are no longer
involved or interested and so unless others pick up the baton, there
will be little progress. I still run 5.2 on sites simply because it's
simply uneconomic to change them.
Well said. Anybody who says "the majority of users don't use this feature,
so that's a good enough reason to remove it" are ignoring the vast amount of
code out there that will be affected.
Now moving code forward, handling every warning and simply keeping code
running from version to version, one hits the problem that sites that
are reliant on older versions of PHP can't easily be run with newer
versions. I've managed to build a way around that problem by now running
php-fpm/nginx which allows me to actually run the same code across
multiple versions of PHP. But one has to be very careful about just what
is changed at each step, so in my book, unless there is some good
security reason to stop something working then it should remain for BC
reasons.
Hear hear!
Others are of the opinion that all current PHP code is a mess and my
reaction to that is ... well use a different language then! ...
I echo that thought. Millions of developers chose to use PHP because it gets
the job done, and once they have written coder that works they expect it to
keep working with future versions of the language. This is called
"longevity", and all organisations expect their investment in software to
last for a significant amount of time. If their application has to be
recoded every couple of years they will regard the language as being
"unstable" and move on to something else. I have worked with two other
languages for over a decade each, and as these languages were maintained by
"professionals" they could guarantee that code written on day 1 of the first
year would still be running ten years later.
expecting the vast majority of users to rename every function ( on of
the proposals for PHP7 ) or switch to a strictly typed method of working
is simply not going to happen, so I have no problem with people adding
new extensions which allow these different sytles of working as long as
the underlying procedural style of working is maintained in as BC a way
as possible, so things like 'var' and a number of the 7.1 deprecation
proposals simply destroy BC with little gain to a pure OO based version
of PHP anyway.
All those who want to work with a 100% pure OO language should stop using
PHP and switch to Java. Stop complaining about the quirks in PHP because
there are quirks in every language. Stop trying to make the language perfect
as your definition of "perfect" does not match that used by others who are
more than satisfied with "good enough".
--
Tony Marston
Tony Marston wrote on 06/03/2016 08:59:
I have worked with two other languages for over a decade each, and as
these languages were maintained by
"professionals" they could guarantee that code written on day 1 of the
first
year would still be running ten years later.
Out of curiosity, which languages are you referring to? It would be
interesting to see if there are specific lessons we can learn from their
development and compatibility processes, even if the ecosystem they
exist in is very different to ours.
Regards,
Rowan Collins
[IMSoP]
"Rowan Collins" wrote in message news:56DD68C0.1090407@gmail.com...
Tony Marston wrote on 06/03/2016 08:59:
I have worked with two other languages for over a decade each, and as
these languages were maintained by
"professionals" they could guarantee that code written on day 1 of the
first
year would still be running ten years later.Out of curiosity, which languages are you referring to? It would be
interesting to see if there are specific lessons we can learn from their
development and compatibility processes, even if the ecosystem they
exist in is very different to ours.
COBOL and UNIFACE.
--
Tony Marston
It showcases what the studies about UI/UX found out about duplicated
behavior (or call it aliasing, multiple choices for the same thing, ...).People are confused and we can and should avoid that.
Yes, duplication isn't good and we should avoid adding new duplication
without a good reason.
However breaking compatibility isn't good either. Adding breaks not only
invalidates code but also tutorials, books, etc. which might confuse
readers more (while I admit, that a book teaching "var" might be
questionable in other ways, too)
Quick Googling brings this tutorial, which first teaches "var"
to get started and then changes to public/private/protected in a
later step:
http://www.killerphp.com/tutorials/php-objects-page-3/
The "var" keyword once emitted an
E_STRICTbut I guess it was turned off
again because too many people were complaining as they are now.
One could argue those were other times - I doubt anybody maintains a
single code base for both PHP 4 and PHP 7. While in early PHP 5 times it
had been common that people tried to produce code working on PHP 4 and
PHP 5 without notices.
johannes
If "var" is automatically translated into "public", and has been since PHP 5
emerged, and has been documented to behave in this way, then what does it
cost to leave it that way? Answer: NOTHING!
Yeah. This is actually very true.
--
Cheers,
Kubis