Den 2019-04-24 kl. 19:43, skrev Chase Peeler:
On Wed, Apr 24, 2019 at 1:27 PM Marco Pivetta <ocram...@gmail.com> wrote:
On Wed, 24 Apr 2019, 19:25 Christian Schneider, <cschn...@cschneid.com>
wrote:
Am 24.04.2019 um 19:13 schrieb Marco Pivetta <ocram...@gmail.com>:
On Wed, 24 Apr 2019, 19:10 Christian Schneider, <cschn...@cschneid.com
wrote:
Am 24.04.2019 um 19:01 schrieb Peter Kokot <peterko...@gmail.com>:
just a friendly reminder that by the time one writes an email here
these tags can be already replaced with the usual ones.
A friendly reminder that some people are hosting customer code which
they do not want to touch but will get support requests once the code
breaks.
- Chris
That's normal? Everyone has projects to maintain, and breaking changes
are common: they're gonna call you for one anyway: if you don't like
that,
then you are in the wrong line of business.
See Chase Peeler's point: A breaking change should have a reward big
enough to justify it.
And that's what where we (including Zeev Suraski and other core
developers) disagree.
- Chris
Run a fixer: they are out there, and they are extremely stable too.
Also a good chance to finally take a look at code that has been rotting in
a hard drive for too much time.
All of that takes time though. I have 6,787 short opening tags found. Even
if I use a fixer to generate a diff, or, to fix them and then examine the
diff in a pull request... that's going to take a LOT of time. It's going to
start getting messy if I find false positives and need to exclude changes.
It still doesn't address the impact of changes that aren't found. Are you
100% positive that the fixers out there will catch EVERY single instance?
php-cs-fixer doesn't update <? inside of strings. If that's generating
dynamic code, then that's not getting caught.
The output from php-cs-fixer just generated a diff file that was 161,000
lines long. But yea, that's something I can scan through real quick and
make sure nothing is going to get broken. No chance I'll miss something
either.
I would LOVE to have the time to go through our legacy code and clean out
old stuff. We have a lot of technical debt that, while we aren't paying it
off at the moment, it's gaining any interest either. We also have plenty
that is. It's tough to justify putting off the stuff that is gaining
interest to focus on stuff that isn't so we can fix short tags.
I don't work for a software company. I develop an internal application for
a non-software company. There are 2 other developers and enough work for 10
developers. It's going to be VERY hard for me to get management to approve
putting off projects that have a direct impact on our business in order to
upgrade to PHP 8 when that time comes. I think you are going to find that's
a pretty common occurrence, and the adoption rate of PHP 8 is going to be
VERY low. Especially when more and more user-friendly alternatives like
python and node are coming along. It was one thing when the options were
RoR, ASP.NET, and JSP. That's not the ecosystem anymore, and it's only
going to provide additional user friendly opportunities in the next couple
of years leading up to PHP8.
Can someone PLEASE tell me the positive gains this RFC will accomplish that
justifies risking:
1.) Losing market share
2.) losing credibility
3.) removing a large number of libraries that are fine from a technical
aspect, but will stop working due to the existence of <?
4.) new security risks (code leaks that are more likely than the code leaks
the RFC seeks to prevent)
Hi,
I did a quick check on two open source libraries that I'm using,
namely Smarty templating library and Revive ad server. A quick
glance at hand shows that they both uses the <? tag in their
latest release. Smarty 3.1.33 was released 17/9 2018 and
Revive 4.2.0 was released 23/4 2019.
It would be interesting to see if there is any benefit in fixing this
feature for these two well-established libraries? I think that both
these libraries will adapt, but how long will it take... Regarding
your points above I don't see any added value that this feature
brings for me as a user of these two libraries, since I'm quite
happy with the functionality they provide as is. How then the
developers see it is not up to me to judge.
r//Björn L
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
