> On 11 Oct 2019, at 02:59, Walter Parker <walt...@gmail.com> wrote:
>
> On Thu, Oct 10, 2019 at 10:36 AM Chase Peeler <chasepee...@gmail.com> wrote:
>
>>
>>
>> On Thu, Oct 10, 2019 at 1:30 PM Walter Parker <walt...@gmail.com> wrote:
>>
>>>>
>>>>
>>>> No. The compromise is funding a ferry system. Or laying Internet between
>>>> them. Or a passenger pigeon mail route.
>>>>
>>>> Sometimes compromise requires deep discussion about the motivations for
>>>> each side and coming to a lateral, mutually acceptable, solution.
>>>>
>>>> But we'd rather not discuss motivations and just bicker about the
>>> surface
>>>> results. I.e., argue the X, rather than the Y, of these little XY
>>> problems
>>>> we're solving.
>>>>
>>>>
>>>>
>>> Build a ferry system is alternative to building bridge. I can see that as
>>> a
>>> compromise, I can also see that as a separate project created to serve
>>> demand after the the bridge project is rejected. Where a ferry system is
>>> started because there is still demand for transit, just not enough demand
>>> to pay for a bridge.
>>>
>>> With respect to the backtick proposal, what is the "ferry" project? Do we
>>> have to come up with one before we can cancel the "bridge" project or can
>>> we cancel the "bridge" project on its own merits and then discuss a future
>>> project that solves the actual underlying problem?
>>>
>>> "Ferry" projects might be: more/better training on PHP, better
>>> documentation so that the backtick is no longer an "obscure" feature to
>>> those that don't have a shell/Unix/Perl background, tooling to warn people
>>> when they misuse this feature.
>>>
>>>
>>>
>> To the side that says "There is absolutely no reason we need to go to, or
>> communicate with, the island in the first place," a ferry project isn't a
>> compromise. The position of the "anti-bridge" builders isn't because they
>> are against building bridges - it's because they are against spending
>> resources on attempts to get to the island in the first place. The other
>> side might have valid arguments on why we need to get to the island, but,
>> just proposing different ways to get there isn't compromising with the side
>> that doesn't want to go there.
>>
>
> I think you may have just created a strawman for the anti-bridge position.
> There are famous anti-bridge cases, like the Bridge to Nowhere in Alaska
> (if you don't remember, there was an island in Alaska that had 50 people
> and Senator Stevens wanted to replace the existing ferry system with a $398
> million bridge). People complained about the bridge not because they wanted
> the islanders to to isolated, but because it was poor use of money when
> there where bigger and more urgent problems.
>
> To bring this back to PHP, is the backtick really a urgent problem of
> enough magnitude that it justifies the cost of a BC break in unknown amount
> of PHP code that has been functional for years. If this proposal passes
> (and the follow up to remove it which I'm certain will be proposed), then
> this is one that leaves people on the island as they will either be stuck
> on an old version of PHP or have to pay to update the code. This pushes the
> costs on them to solve a an existing issue that 20 years after it was
> created and is now an issue because a new generation of coders, unaware of
> history, find the existing syntax not to there taste/a poor design. Why are
> we giving priority to people that haven't taken the time to educate
> themselves over people that did and used programming style that used to
> common?
>
>
>>
>>
>>> Walter
>>>
>>> --
>>> The greatest dangers to liberty lurk in insidious encroachment by men of
>>> zeal, well-meaning but without understanding. -- Justice Louis D.
>>> Brandeis
>>>
>>
>>
>> --
>> Chase Peeler
>> chasepee...@gmail.com
>>
>
>
> --
> The greatest dangers to liberty lurk in insidious encroachment by men of
> zeal, well-meaning but without understanding. -- Justice Louis D. Brandeis
(Sorry, wrong account previously, so didn’t sent to the list)
Hi Walter,
The RFC at the centre of this ridiculous string of analogies is about one
thing: deprecate (i.e. show a deprecation message) about the backtick operator.
The RFC specifically doesn’t lay out a timeline for actual removal, it doesn’t
even hint at “well it’ll just be automatically removed”.
So this RFC breaks *nothing*.
Yes, it does lead to the situation where it’s likely that a followup RFC will
propose removing the (then) deprecated feature - perhaps 9.0, perhaps it’ll be
discussed pre-9.0, and held off until 10.0? But any such change will then
require *another* vote, with another round of discussions and no doubt
ridiculous analogies.
And at that time, after several years of warnings about deprecation, Nikita or
someone else will likely pop up with some analysis of projects to show usage
*at the time*.
If the only reason to keep a dangerous operator is “well a small subset of
people use it”, marking it as *deprecated* is how you signal to those people
that the feature will likely be removed in a future version.
The argument about “shell style scripts” that are on a server which constantly
gets updated to the newest release but never gets any maintenance to the
scripts is a ridiculous fantasy.
There is zero chance someone is dist-upgrading from one release to the next
through enough versions that they get to one where the distro-provided php is
such that backticks are actually removed, and yet the only thing that breaks is
the backticks.
Cheers
Stephen
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
