8 years ago by Tony Marston — view source

unread

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

8 years ago by kelerest123@gmail.com — view source

unread

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

8 years ago by James Titcumb — view source

unread

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

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.

8 years ago by Tony Marston — view source

unread

"James Titcumb" wrote in message
news:CAKnqCEY7art1GUWG=Pm0wyPGQmYp0Dq8oxdohgBkSGq+O_BTZw@mail.gmail.com...

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

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

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

8 years ago by Rowan Collins — view source

unread

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

If 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]

8 years ago by Tony Marston — view source

unread

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

If 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

8 years ago by Rowan Collins — view source

unread

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]

8 years ago by Rowan Collins — view source

unread

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]

8 years ago by Fleshgrinder — view source

unread

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,

The misuse of "var" as it was explained is reason alone to take action.

--
Richard "Fleshgrinder" Fussenegger

8 years ago by Tony Marston — view source

unread

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/14610

Regards,

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

8 years ago by Rowan Collins — view source

unread

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/14610

Regards,

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]

8 years ago by Fleshgrinder — view source

unread

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

8 years ago by Tony Marston — view source

unread

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_STRICT but 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

8 years ago by Lester Caine — view source

unread

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.

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

8 years ago by Colin O'Dell — view source

unread

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

8 years ago by Rowan Collins — view source

unread

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]

8 years ago by Lester Caine — view source

unread

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

8 years ago by Rowan Collins — view source

unread

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]

8 years ago by Lester Caine — view source

unread

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

8 years ago by Rowan Collins — view source

unread

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]

8 years ago by Lester Caine — view source

unread

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

8 years ago by Fleshgrinder — view source

unread

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

8 years ago by Rowan Collins — view source

unread

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]

8 years ago by Fleshgrinder — view source

unread

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

8 years ago by Rowan Collins — view source

unread

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 that E_STRICT is 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]

8 years ago by Fleshgrinder — view source

unread

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

8 years ago by Tony Marston — view source

unread

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

8 years ago by Fleshgrinder — view source

unread

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?

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

8 years ago by Lester Caine — view source

unread

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

8 years ago by Fleshgrinder — view source

unread

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

8 years ago by Walter Parker — view source

unread

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

8 years ago by Stephen Coakley — view source

unread

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

8 years ago by Fleshgrinder — view source

unread

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

8 years ago by Tony Marston — view source

unread

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

8 years ago by Rowan Collins — view source

unread

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]

8 years ago by Tony Marston — view source

unread

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

8 years ago by Rowan Collins — view source

unread

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]

8 years ago by Tony Marston — view source

unread

"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

8 years ago by James Titcumb — view source

unread

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.

8 years ago by Tony Marston — view source

unread

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

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

8 years ago by James Titcumb — view source

unread

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.

8 years ago by Arvids Godjuks — view source

unread

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

8 years ago by come@opensides.be — view source

unread

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)

8 years ago by Rowan Collins — view source

unread

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]

8 years ago by Andrew Brown — view source

unread

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

8 years ago by Arvids Godjuks — view source

unread

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.

8 years ago by Yasuo Ohgaki — view source

unread

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

8 years ago by Rowan Collins — view source

unread

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]

8 years ago by Fleshgrinder — view source

unread

@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

8 years ago by Glenn Eggleton — view source

unread

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

8 years ago by Tony Marston — view source

unread

"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

8 years ago by Rowan Collins — view source

unread

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]

8 years ago by Tony Marston — view source

unread

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

8 years ago by Tony Marston — view source

unread

"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

8 years ago by Rowan Collins — view source

unread

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]

8 years ago by Tony Marston — view source

unread

"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

8 years ago by johannes@schlueters.de — view source

unread

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_STRICT but 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

8 years ago by kelerest123@gmail.com — view source

unread

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

8 years ago by kelerest123@gmail.com — view source

unread

Change for the sake of change is bad, no argument there. Change for the

sake of progress is not and totally normal.

Can you please specify what kind of progress do see in the var keyword removal? I see only a BC break.

Very best regards,
Kubis Pandian-Fowler

Od: Fleshgrinder
Odoslané: ‎štvrtok‎, ‎3‎. ‎marca‎ ‎2016 ‎22‎:‎23
Komu: internals@lists.php.net

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.

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.

--
Richard "Fleshgrinder" Fussenegger

8 years ago by Walter Parker — view source

unread

Change for the sake of change is bad, no argument there. Change for the

sake of progress is not and totally normal.

Can you please specify what kind of progress do see in the var keyword
removal? I see only a BC break.

Very best regards,
Kubis Pandian-Fowler

Od: Fleshgrinder
Odoslané: ‎štvrtok‎, ‎3‎. ‎marca‎ ‎2016 ‎22‎:‎23
Komu: internals@lists.php.net

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

It is a disagreement over language design, the Python way vs the Perl way.
The Perl way says: There is more than one way to do things
The Python way says: There is one correct way to do things. Other methods
should be removed.

There is a desire among some PHP people to have the language be more like
the Python mindset.

--
The greatest dangers to liberty lurk in insidious encroachment by men of
zeal, well-meaning but without understanding. -- Justice Louis D. Brandeis

8 years ago by Tony Marston — view source

unread

"Walter Parker" wrote in message
news:CAMPTd_BvX-vcnm5UejW8B_162AVmVx_+9a=EpZX3yn5hz5dxfw@mail.gmail.com...

Change for the sake of change is bad, no argument there. Change for the
sake of progress is not and totally normal.

Can you please specify what kind of progress do see in the var keyword
removal? I see only a BC break.

Very best regards,
Kubis Pandian-Fowler

Od: Fleshgrinder
Odoslané: ?štvrtok?, ?3?. ?marca? ?2016 ?22?:?23
Komu: internals@lists.php.net

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

It is a disagreement over language design, the Python way vs the Perl way.
The Perl way says: There is more than one way to do things
The Python way says: There is one correct way to do things. Other methods
should be removed.

There is a desire among some PHP people to have the language be more like
the Python mindset.

Just because "some" people wish to change the language so that it suits
their personal tastes is no reason to force millions of other developers to
suffer because of a totally unnecessary BC break.

--
Tony Marston

8 years ago by Fleshgrinder — view source

unread

[...] Mind you, those languages were maintained by groups of
competent professionals and not an army of chimpanzees.

I will not reply fully to your last message because it was yet again
littered with personal insults and an extremely aggressive tone. I
already complained earlier about your tone and I protest at this point
again. Please read some code of conducts out there and maybe those that
are currently being discussed to be added to PHP.

Should you truly believe that I am a complete idiot (or chimpanzee), so
be it, I can life with that. I will also refrain from listing all the
time intervals I have spent with PHP and/or other languages. This is a
professional talk and not a---excuse my french---dick-measuring contest.
I for one enjoy the disagreement because we can all learn from each
other. In Austria we have an idiom that says "Du kannst auch von einem
Idioten etwas lernen," this boils down to "you can also learn something
from an idiot". Just think about it, every person on this earth knows at
least something you don't. Ergo, maybe just maybe you can learn
something from the army of chimpanzees here.

Change for the sake of change is bad, no argument there. Change for the

sake of progress is not and totally normal.

Can you please specify what kind of progress do see in the var keyword removal? I see only a BC break.

Very best regards,
Kubis Pandian-Fowler

The main reason in my opinion to go done this road till PHP 8 or 9 is
simplification for users based on UI/UX research and a very few papers
on language design (links and other material posted earlier).
Duplication and exceptions in handling (e.g. argument order) result in
various problems for users:

Is this an alias or does it work differently? Let's check the docs.
This is an alias, we should not use it because it might get removed.
This is an alias, it might add performance overhead.
What was the argument order here again? Let's check the docs.
...

Just to name a few silly things that I encounter regularly. We even had
some really evil example here in this thread were the var keyword was
used to indicate to a DIC that this property requires injection. After
all it is about simplification of the language's interface.

It is a disagreement over language design, the Python way vs the Perl
way.
The Perl way says: There is more than one way to do things
The Python way says: There is one correct way to do things. Other
methods should be removed.

Yes, that is the core of the problem here.

--
Richard "Fleshgrinder" Fussenegger

8 years ago by Tony Marston — view source

unread

wrote in message news:56DDEF7B.6080309@fleshgrinder.com...

[...] Mind you, those languages were maintained by groups of
competent professionals and not an army of chimpanzees.

I will not reply fully to your last message because it was yet again
littered with personal insults and an extremely aggressive tone.

I disagree with your definition of "personal insult" and "aggressive tone".
I could also accuse all the supporters of this BC break of having an
aggressive tone, but that would be because of my delicate and sensitive
nature. :)

I
already complained earlier about your tone and I protest at this point
again. Please read some code of conducts out there and maybe those that
are currently being discussed to be added to PHP.

Should you truly believe that I am a complete idiot (or chimpanzee), so
be it, I can life with that. I will also refrain from listing all the
time intervals I have spent with PHP and/or other languages. This is a
professional talk and not a---excuse my french---dick-measuring contest.
I for one enjoy the disagreement because we can all learn from each
other. In Austria we have an idiom that says "Du kannst auch von einem
Idioten etwas lernen," this boils down to "you can also learn something
from an idiot". Just think about it, every person on this earth knows at
least something you don't. Ergo, maybe just maybe you can learn
something from the army of chimpanzees here.

The only thing I am learning here is that there are too many cooks spoiling
the broth. There are too many people who want to change the language into
something it was not meant to be. There are too many people who have this
notion of language "purity" and "perfection" and want to force their
personal views on the whole of the PHP development community. They don't
care about all those BC breaks which prevent the quick take-up of new
versions.

When large organisations invest in their software applications they expect
stability and longevity. By creating BC breaks with every new version of the
language you are destroying those expectations and sending a message to
millions of developers "Don't bother using this language as what you write
today won't work in 5 year's time".

Change for the sake of change is bad, no argument there. Change for the

sake of progress is not and totally normal.

Can you please specify what kind of progress do see in the var keyword
removal? I see only a BC break.

Very best regards,
Kubis Pandian-Fowler

The main reason in my opinion to go done this road till PHP 8 or 9 is
simplification for users based on UI/UX research and a very few papers
on language design (links and other material posted earlier).
Duplication and exceptions in handling (e.g. argument order) result in
various problems for users:

This has not been a problem so far for the millions of developers who have
created millions of web sites and made PHP the number 1 language for the
internet. If others have a problem then perhaps the problem is with them and
not the language.

Just to name a few silly things that I encounter regularly. We even had
some really evil example here in this thread were the var keyword was
used to indicate to a DIC that this property requires injection. After
all it is about simplification of the language's interface.

It you can enhance the language without destroying existing functionality I
will consider you to be a competent professional.

--
Tony Marston

8 years ago by Lester Caine — view source

unread

The only thing I am learning here is that there are too many cooks
spoiling the broth. There are too many people who want to change the
language into something it was not meant to be. There are too many
people who have this notion of language "purity" and "perfection" and
want to force their personal views on the whole of the PHP development
community. They don't care about all those BC breaks which prevent the
quick take-up of new versions.

When large organisations invest in their software applications they
expect stability and longevity. By creating BC breaks with every new
version of the language you are destroying those expectations and
sending a message to millions of developers "Don't bother using this
language as what you write today won't work in 5 year's time".

I've been providing a caller management system since the early 90's. The
JOB it does has not changed in 20+ years, although the reports have
changed over time. This was originally based on proprietary terminals
... PC's were not something you found out on the counters then. As that
changed, these were replaced with a PHP based application and became web
based. Still doing exactly the same job. That job has not changed even
today, but some sites that have introduced 'improvements' such as
virtual desktops and thin client devices have made the job more and more
difficult. One site can't even tell me which building a user is working
from because the system does not identity the physical hardware.
Fortunately the 'older' services still work so one can at least bypass
it and retain the location information, but they have invested too much
to admit the real mistake! Problems like this get missed when 'improving
services' goes blindly down a particular path, and PHP seems to be stuck
in such a rut with new features like Reflections, Traits, magic
functions and so on when the vast majority of current applications
simply don't need to be changed at all. I'm once again going through
perfectly functional code to clear up warnings are now appearing on a
server I though HAD all been brought up to be PhP5.5 clean. And I know
I'll have to do the same exercise again later for PHP7. Don't say "Just
switch off the warnings" ... THAT is what has built up the backlog of
work from PHP5.2 ... so adding even more warnings is not helping improve
PHP ...

--
Lester Caine - G8HFL

8 years ago by Andrew Brown — view source

unread

the main argument against removing var that I continue to hear is that 'my
old code won't work anymore because of this unnecessary BC break'. but the
thing is, your code will continue to work. unless you choose to upgrade
your PHP version. if you stay on the current major version, it will
continue to work just fine. just like your PHP4 constructors will continue
to work on version 4, etc, etc.

Of course, someone will say, 'but I want the new features and speed
improvements', which is valid. But I feel it is unfair to the language
developers, with all of the work they put in, to expect that we as users
of the language don't have to put in any effort to upgrade to a new major
version. and I would imagine changing your vars to public is a
relatively simple update, compared to some other possible BC breaks.

If we, as application developers, had duplicate code, or code that was
often the source of confusion, we would probably do our best to remove the
duplication and confusion, even if (technically) the code wasn't
hurting/breaking anything. this makes our future work easier on ourselves
or future developers. I think it is unfair of us to expect any different
from the language maintainers.

here's an example that actually occurred in application code of mine. by an
oversight I had 2 helper functions named validation_state() and
validationState(). the intention of both was the same thing, and to start
they both did exactly the same thing. Some places in my app used
validation_state and some other places used validationState().
technically the code worked, so I thought nothing of it. then one day I
made a minor change to validation_state() but forgot that
validationState() existed, and didn't make the changes there as well.
This caused inconsistencies in my application, and the problem was not
immediately apparent. after that occurred I decided to spend 30 minutes,
and completely remove the validationState() function, and replace all
occurrences of it with validation_state(). Yes, I had to put in a little
work, but it was worth it for cleaner, more consistent code.

consistency is key to make the language easy to understand for the language
maintainers, and for the language users, and especially for new users of
the language.

thanks,

The only thing I am learning here is that there are too many cooks
spoiling the broth. There are too many people who want to change the
language into something it was not meant to be. There are too many
people who have this notion of language "purity" and "perfection" and
want to force their personal views on the whole of the PHP development
community. They don't care about all those BC breaks which prevent the
quick take-up of new versions.

When large organisations invest in their software applications they
expect stability and longevity. By creating BC breaks with every new
version of the language you are destroying those expectations and
sending a message to millions of developers "Don't bother using this
language as what you write today won't work in 5 year's time".

I've been providing a caller management system since the early 90's. The
JOB it does has not changed in 20+ years, although the reports have
changed over time. This was originally based on proprietary terminals
... PC's were not something you found out on the counters then. As that
changed, these were replaced with a PHP based application and became web
based. Still doing exactly the same job. That job has not changed even
today, but some sites that have introduced 'improvements' such as
virtual desktops and thin client devices have made the job more and more
difficult. One site can't even tell me which building a user is working
from because the system does not identity the physical hardware.
Fortunately the 'older' services still work so one can at least bypass
it and retain the location information, but they have invested too much
to admit the real mistake! Problems like this get missed when 'improving
services' goes blindly down a particular path, and PHP seems to be stuck
in such a rut with new features like Reflections, Traits, magic
functions and so on when the vast majority of current applications
simply don't need to be changed at all. I'm once again going through
perfectly functional code to clear up warnings are now appearing on a
server I though HAD all been brought up to be PhP5.5 clean. And I know
I'll have to do the same exercise again later for PHP7. Don't say "Just
switch off the warnings" ... THAT is what has built up the backlog of
work from PHP5.2 ... so adding even more warnings is not helping improve
PHP ...

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

--

--
Andrew M. Brown

8 years ago by Lester Caine — view source

unread

TRIMMING TO COMPENSATE FOR TOP POSTING !!!!

the main argument against removing var that I continue to hear is that 'my
old code won't work anymore because of this unnecessary BC break'. but the
thing is, your code will continue to work. unless you choose to upgrade
your PHP version. if you stay on the current major version, it will
continue to work just fine. just like your PHP4 constructors will continue
to work on version 4, etc, etc.

This is exactly why PHP5.2 and PHP5.3 are still so common. MAKING the
changes to allow code to work on later versions simply takes a resource
that is not available, and while PHP does not support these older
versions, ISP and others do. It's the easy option, and there are many
examples where ISP's forced an upgrade on their PHP only to have so many
broken sites they had to back peddle.

Of course, someone will say, 'but I want the new features and speed
improvements', which is valid. But I feel it is unfair to the language
developers, with all of the work they put in, to expect that we as users
of the language don't have to put in any effort to upgrade to a new major
version. and I would imagine changing your vars to public is a
relatively simple update, compared to some other possible BC breaks.

The speed improvements implemented in PHP7 were unrelated to the changes
made to the language. They were specifically designed with that in mind,
but they did require that every extension was reworked to be compatible.
Another area that the work load grows. But the fact that security fixes
are only applied to recent versions makes that a reason why one has to
upgrade the platform ... or simply spend time back porting those
security fixes. But in my book, there is no reason new improvements
can't be kept to new extensions, so one can leave them off if one is not
using them. I don't use MySQL -so I don't need any MySQL extensions.

If we, as application developers, had duplicate code, or code that was
often the source of confusion, we would probably do our best to remove the
duplication and confusion, even if (technically) the code wasn't
hurting/breaking anything. this makes our future work easier on ourselves
or future developers. I think it is unfair of us to expect any different
from the language maintainers.

Having to add 'compatibility' fixes has been one way of allowing older
and newer code to co-exist, and often the duplicate code is a result of
the upgrade process. But you next point is one of my biggest grumble ...

here's an example that actually occurred in application code of mine. by an
oversight I had 2 helper functions named validation_state() and
validationState(). the intention of both was the same thing, and to start
they both did exactly the same thing. Some places in my app used
validation_state and some other places used validationState().
technically the code worked, so I thought nothing of it. then one day I
made a minor change to validation_state() but forgot that
validationState() existed, and didn't make the changes there as well.
This caused inconsistencies in my application, and the problem was not
immediately apparent. after that occurred I decided to spend 30 minutes,
and completely remove the validationState() function, and replace all
occurrences of it with validation_state(). Yes, I had to put in a little
work, but it was worth it for cleaner, more consistent code.

The changes between Smarty 2 and Smarty 3 incorporated similar changes
and the 'validation_state' style of naming was replaced by the 'more
modern' validationState style. So you seem to be going against 'current
practice'. My problem having decided that PHP7 should avoid using the
'BC' duplicate functions and go with 'clean' Smarty3 naming, there are
bugs on a number of sites now with the old style and I've not yet
managed to isolate the faulty code ... so I've had to switch back on the
'BC' hacks just to keep them working :( It all takes time that perhaps
need not have been wasted since ALL that changed was some ones
preference of coding style :(

consistency is key to make the language easy to understand for the language
maintainers, and for the language users, and especially for new users of
the language.

Since the bulk of material a new user will use is style following 10
year old examples and MySQL is still the norm, new users will not see
the changes anyway ... We do need GOOD modern practice examples on how
things should be done today. That is what is missing.

( DON'T NEED TO DUPLICATE SIG LINES but then your email client should be
modern enough to recognise the '--' flag? )

--
Lester Caine - G8HFL

8 years ago by Fleshgrinder — view source

unread

@Tony Marston: I feel directly attacked and offended and others have the
feeling too, that is the definition of an insult. That being said, I am
staying constructive the whole time and do not avoid communication with
you or anyone else because I think we are discussing an important topic.
BUT! As Rowan Collins said, keep your emotions aside.

"Rowan Collins" wrote in message news:56DD68C0.1090407@gmail.com...

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.

The history of COBOL shows that it was completely overhauled very often
and major changed and breaks had to be made in order to rescue the
language from being a mess. Later the designers of COBOL faced the same
problems as we face them here right now, people complained about
changes. In the 1990s the language started declining in popularity and
was replaced by others.

Pay special attention to the fact that over 300 dialects of COBOL exist
and that compatibility issues was one of its major criticized points:

https://en.wikipedia.org/wiki/COBOL#Compatibility_issues

Uniface is not a programming language like PHP but they also had
multiple breaking changes between releases. All documented publicly and
easy to find, e.g.:

http://unifaceinfo.com/docs/0905/Uniface_Library_HTML/ulibrary/Migration_5C39D681F0922AFC1A7859CF394AC2F7.html

I am actually not trying to deface Tony Marston here, I am just saying
that it is unavoidable to deprecate and delete features at some point in
order to keep a language tidy and comprehensible while still offering
people and easy way to upgrade.

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?

It would be awesome if we could open up a thread were we discuss these
topics more in-depth. I think that this is really important to help our
language of love to spread and grow further. :)

[...]
I'll have to do the same exercise again later for PHP7. Don't say
"Just switch off the warnings" ... THAT is what has built up the
backlog of work from PHP5.2 ... so adding even more warnings is not
helping improve PHP ...

I am not sure if I wrote that warnings should be simply switched off but
I definitely wrote that this is a possible "solution" for people who
know about the actual problem but do not want their logs to be littered
with them. It definitely should not be the course of action for normal
users.

Your point however is very important because we really have to be very
sensible about such changes. Introducing too many clean-ups is a
problems. We saw PHP 6 simply ceasing to exist because the changes were
too enormous and we saw it happening to Python 3 were the changes were
not well received by the community and now they have to support two
major versions (I do not know the details here).

Which brings me too ...

[...] It all takes time that perhaps need not have been wasted since
ALL that changed was some ones preference of coding style :(

That we should definitely avoid. I do not consider the var keyword
being a discussion about coding style preferences---this decision was
already made in PHP 5! The public keyword was introduced and it
superseded the var keyword including an E_STRICT error. Hence, this
discussion is not about whether this was good, correct, or whatever
decision: it is already done! This is about clean-up of the old unwanted
way of doing it and by now maybe even a discussion about clean-up in
general.

TL;DR Clean-up is important but there must be an easy to follow
migration path and enough time. We have both here, still +1

--
Richard "Fleshgrinder" Fussenegger

8 years ago by Walter Parker — view source

unread

That we should definitely avoid. I do not consider the var keyword
being a discussion about coding style preferences---this decision was
already made in PHP 5! The public keyword was introduced and it
superseded the var keyword including an E_STRICT error. Hence, this
discussion is not about whether this was good, correct, or whatever
decision: it is already done! This is about clean-up of the old unwanted
way of doing it and by now maybe even a discussion about clean-up in
general.

TL;DR Clean-up is important but there must be an easy to follow
migration path and enough time. We have both here, still +1

--
Richard "Fleshgrinder" Fussenegger

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?

Have programmer become more confused? This alias does not appear to have
been an issue for the last 12 years.

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)?

Walter

--
The greatest dangers to liberty lurk in insidious encroachment by men of
zeal, well-meaning but without understanding. -- Justice Louis D. Brandeis

8 years ago by Tony Marston — view source

unread

wrote in message news:56DF3DFB.10007@fleshgrinder.com...

@Tony Marston: I feel directly attacked and offended and others have the
feeling too, that is the definition of an insult. That being said, I am
staying constructive the whole time and do not avoid communication with
you or anyone else because I think we are discussing an important topic.
BUT! As Rowan Collins said, keep your emotions aside.

The fact that one person sees that as a personal insult while millions of
others do not just points to the low threshold of that individual. If I were
to write "you are a f*cking idiot" then that WOULD be a personal insult in
everybody's eyes, but what I wrote was nowhere near being that personal or
that insulting.

The fact that that you take offence at my opinion is balanced by the fact
that I take offence whenever someone suggests breaking my favourite language
FOR NO GOOD REASON other than a personal preference.

"Rowan Collins" wrote in message news:56DD68C0.1090407@gmail.com...

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.

The history of COBOL shows that it was completely overhauled very often
and major changed and breaks had to be made in order to rescue the
language from being a mess.

As a developer who went through several COBOL upgrades I can attest to the
fact that BC breaks were extremely rare and only for a good reason. My code
was never affected simply because I never used any of the dodgy features
(such as ALTER ... GO TO ...) which were removed. My company, which was
using a framework which I had designed and wriiten, upgraded from COBOL-74
to COBOL-85 without ANY issues whatsoever.

Later the designers of COBOL faced the same
problems as we face them here right now, people complained about
changes. In the 1990s the language started declining in popularity and
was replaced by others.

You are missing the fact that there are still billions of lines of working
COBOL code out there simply because it would be too expensive to rewrite all
that code in a different language.

Pay special attention to the fact that over 300 dialects of COBOL exist
and that compatibility issues was one of its major criticized points:

https://en.wikipedia.org/wiki/COBOL#Compatibility_issues

Uniface is not a programming language like PHP but they also had
multiple breaking changes between releases. All documented publicly and
easy to find, e.g.:

Irrelevant. I personally started with UNIFACE v5 and move through v6 and v7
without any BC breaks. How was this possible? Because I never used those
features which caused problems and were later removed.

http://unifaceinfo.com/docs/0905/Uniface_Library_HTML/ulibrary/Migration_5C39D681F0922AFC1A7859CF394AC2F7.html

I am actually not trying to deface Tony Marston here, I am just saying
that it is unavoidable to deprecate and delete features at some point in
order to keep a language tidy and comprehensible while still offering
people and easy way to upgrade.

Imposing your personal ideas of "tidy" and "comprehensible" on the entire
PHP userland community is not something that pleases that community.

The easiest way to upgrade does not involve having to change working code
FOR NO GOOD REASON.

--
Tony Marston

8 years ago by Rowan Collins — view source

unread

Tony Marston wrote on 09/03/2016 10:31:

As a developer who went through several COBOL upgrades I can attest to
the fact that BC breaks were extremely rare and only for a good
reason. My code was never affected simply because I never used any of
the dodgy features (such as ALTER ... GO TO ...) which were removed.

...

I personally started with UNIFACE v5 and move through v6 and v7
without any BC breaks. How was this possible? Because I never used
those features which caused problems and were later removed.

OK, so it was not that there were no BC breaks, just that they happened
not to affect you, because you weren't using the removed features. So
if, to give an example that was recently discussed, you never used PHP's
create_function() function, you would be able to upgrade to a version
that removed it without any changes. Clearly, this is not the same thing
as "never break BC".

This leaves us back with a decision about which BC breaks are
acceptable, discussion of which includes how many people use the
feature, how it will affect them, and what the benefits are in the
particular case.

Now, I think it's safe to assume that the example of "var" is something
that a lot of code will be using, and I have already said that, in this
particular case, I don't think the benefits outweigh the costs. But I
come to that conclusion not on the principle of "change nothing", but on
the principle of weighing costs and benefits, which I am happy to delve
into the details of on a case-by-case basis.

Regards,

Rowan Collins
[IMSoP]

8 years ago by Tony Marston — view source

unread

"Rowan Collins" wrote in message news:56E0025C.5040202@gmail.com...

Tony Marston wrote on 09/03/2016 10:31:

As a developer who went through several COBOL upgrades I can attest to
the fact that BC breaks were extremely rare and only for a good reason.
My code was never affected simply because I never used any of the dodgy
features (such as ALTER ... GO TO ...) which were removed.

...

I personally started with UNIFACE v5 and move through v6 and v7 without
any BC breaks. How was this possible? Because I never used those features
which caused problems and were later removed.

OK, so it was not that there were no BC breaks, just that they happened not
to affect you, because you weren't using the removed features. So if, to
give an example that was recently discussed, you never used PHP's
create_function() function, you would be able to upgrade to a version that
removed it without any changes. Clearly, this is not the same thing as
"never break BC".

This leaves us back with a decision about which BC breaks are acceptable,
discussion of which includes how many people use the feature, how it will
affect them, and what the benefits are in the particular case.

No BC breaks are acceptable unless it is for a valid reason, such as a
security issue or a performance issue. Changes in fashion are NOT a good
reason.

--
Tony Marston

8 years ago by Rowan Collins — view source

unread

Tony Marston wrote on 10/03/2016 10:38:

"Rowan Collins" wrote in message news:56E0025C.5040202@gmail.com...

This leaves us back with a decision about which BC breaks are
acceptable, discussion of which includes how many people use the
feature, how it will affect them, and what the benefits are in the
particular case.

No BC breaks are acceptable unless it is for a valid reason, such as a
security issue or a performance issue. Changes in fashion are NOT a
good reason.

OK, so you've listed two reasons that should be accepted, and one that
shouldn't (which is something of a straw man, because I don't think
anyone would directly defend a proposal as "fashionable"). But that's
still not a full definition, as you acknowledge with your "such as".

So, remembering that a lot of this is YOUR opinion, and other people are
perfectly entitled to disagree with you, I would still be interested if
you could come up with a test that you would like applied for what is a
"valid reason" for a BC break. We can't really have a policy of "ask
Tony Marston if it's OK", so the only practical way forward is for us to
come up with such a test.

Scenarios to consider include: creating a new function (someone might
have created a custom function with that name); functionality that
depended on deprecated or unmaintained third-party code; replacing a
scenario that currently generates an error with working code.

Regards,

Rowan Collins
[IMSoP]

8 years ago by Tony Marston — view source

unread

"Andrew Brown" wrote in message
news:CAH=AbGJAnYK1Vra+7mU=Ldcb+9Tp6+qbT9yaVzX60GJ=YJsTnA@mail.gmail.com...

the main argument against removing var that I continue to hear is that 'my
old code won't work anymore because of this unnecessary BC break'. but the
thing is, your code will continue to work. unless you choose to upgrade
your PHP version.

We developers are constantly being told that we should ALWAYS upgrade to
the latest release as soon as possible otherwise our code will be subject to
security flaws.

We would LOVE to upgrade without the fear of having our code stop working
simply because some clever cloggs has broken the language simply removing a
feature that was not doing any harm.

if you stay on the current major version, it will
continue to work just fine. just like your PHP4 constructors will continue
to work on version 4, etc, etc.

PHP 4 constructors have always worked in PHP 5 simply because they were
never deprecated. My PHP 4 code is still running with version 5.6.19

Of course, someone will say, 'but I want the new features and speed
improvements', which is valid. But I feel it is unfair to the language
developers, with all of the work they put in, to expect that we as users
of the language don't have to put in any effort to upgrade to a new major
version.

Apart from installing the new executables there should be NO additional
effort required to upgrade. Valid code which ran in the previous version
should also run in the new version.

and I would imagine changing your vars to public is a
relatively simple update, compared to some other possible BC breaks.

Whether it is simple or not is irrelevant - it is not necessary in the first
place.

If we, as application developers, had duplicate code, or code that was
often the source of confusion, we would probably do our best to remove the
duplication and confusion, even if (technically) the code wasn't
hurting/breaking anything. this makes our future work easier on ourselves
or future developers. I think it is unfair of us to expect any different
from the language maintainers.

What we as userland developers do with our own code only affects us. What
you as core developers do with the language affects every one of the
millions of userland developers all over the world. It does not matter that
certain features have alias names - all a confused developer has to do is
RTFM and all confusion disappears. Unless an exiting feature or function
causes a GENUINE problem then it should be left alone. No effort should be
wasted in taking it out and pissing off a huge number of userland
developers. You as core developers may not like it, but you are there to
serve the needs of the userland community, NOT to enforce your personal
preferences on that community.

here's an example that actually occurred in application code of mine. by an
oversight I had 2 helper functions named validation_state() and
validationState(). the intention of both was the same thing, and to start
they both did exactly the same thing. Some places in my app used
validation_state and some other places used validationState().
technically the code worked, so I thought nothing of it. then one day I
made a minor change to validation_state() but forgot that
validationState() existed, and didn't make the changes there as well.
This caused inconsistencies in my application, and the problem was not
immediately apparent. after that occurred I decided to spend 30 minutes,
and completely remove the validationState() function, and replace all
occurrences of it with validation_state(). Yes, I had to put in a little
work, but it was worth it for cleaner, more consistent code.

How many millions of developers did that change affect? How many
applications did that affect?

consistency is key to make the language easy to understand for the language
maintainers, and for the language users, and especially for new users of
the language.

Define "consistency". Consistency with what?

--
Tony Marston

8 years ago by Rowan Collins — view source

unread

Tony Marston wrote on 09/03/2016 10:09:

What we as userland developers do with our own code only affects us.
What you as core developers do with the language affects every one of
the millions of userland developers all over the world.

I touched on this in another message, but I think you may have
misunderstood the role of some people on this list: most, like you and
me, are participating as interested users and occasional contributors.
Looking at the list of people who've participated in this particular
thread, I'm not sure any one of them has commit rights, or even voting
rights - certainly none are people who I would call "core developers" in
the sense you seem to mean it.

A lot of things are proposed on this list, some gain quick support (like
the ??= proposal), some are controversial; many, many, proposals do not
result in any change to the language, because there is no consensus, or
in some cases, just no interest. It is certainly not the case that if
you stop shouting, this deprecation and removal will quietly go ahead.

Regards,

Rowan Collins
[IMSoP]

[RFC Proposal] var keyword deprecation/removal

Regards,

Regards,

Regards,

Regards,

-- Lester Caine - G8HFL

Regards,

-- Lester Caine - G8HFL

Regards,

-- Lester Caine - G8HFL

Regards,

-- Lester Caine - G8HFL

Regards,

do nothing in PHP 5 (as is),

emit E_STRICT in PHP 7,

emit E_DEPRECATED in PHP 8,

remove in PHP 9

do nothing in PHP 7,

emit E_STRICT in PHP 8,

emit E_DEPRECATED in PHP 9,

remove in PHP 10.

TODO Replace dependency with modern equivalent

Regards,

TODO Replace dependency with modern equivalent

-- Lester Caine - G8HFL

Regards,

Regards,

Regards,

Regards,

Regards,

Regards,

-- Lester Caine - G8HFL

-- Lester Caine - G8HFL

-- Lester Caine - G8HFL

Regards,

Regards,

Regards,

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL

emit `E_STRICT` in PHP 7,

emit `E_DEPRECATED` in PHP 8,

emit `E_STRICT` in PHP 8,

emit `E_DEPRECATED` in PHP 9,

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL