"Arvids Godjuks" wrote in message
news:CAL0xaBF-cx+hijFD=YNiihhKknpxwo0JdO+oNRada=b0jyy...@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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
