[RFC] Deprecate Backtick Operator (V2)

6 years ago by Zeev Suraski — view source — reply

unread

Hi Internals,

I put forward the following RFC "Deprecate Backtick Operator (V2)" for
discussion.

Mark, all,

I’m not sure what planetary alignment or moon phase triggered this recent
compatibility-breaking onslaught, but it can’t go on like this. The fact
we have to repeatedly work to keep things working is an unacceptable
waste of too many people’s time.

When you joined as contributors, you made an informed decision to join an
existing project that isn’t starting from scratch. You’re ~20 years too
late for these kinds of discussions. This ship has sailed so long ago it’s
in the outskirts of the Milky Way by now. Contributions are welcome, but
an endless stream of deprecation proposals that bring absolutely no new
evidence to the table are not contributions. This RFC, indeed, falls
squarely within that category.

All, please focus on adding value to PHP instead of finding ways to break
perfectly working code, even if it’s code you don’t particularly like.

Zeev

6 years ago by Kris Craig — view source — reply

unread

Hi Internals,

I put forward the following RFC "Deprecate Backtick Operator (V2)" for
discussion.

Mark, all,

I’m not sure what planetary alignment or moon phase triggered this recent
compatibility-breaking onslaught, but it can’t go on like this. The fact
we have to repeatedly work to keep things working is an unacceptable
waste of too many people’s time.

When you joined as contributors, you made an informed decision to join an
existing project that isn’t starting from scratch. You’re ~20 years too
late for these kinds of discussions. This ship has sailed so long ago it’s
in the outskirts of the Milky Way by now. Contributions are welcome, but
an endless stream of deprecation proposals that bring absolutely no new
evidence to the table are not contributions. This RFC, indeed, falls
squarely within that category.

All, please focus on adding value to PHP instead of finding ways to break
perfectly working code, even if it’s code you don’t particularly like.

Zeev

We seem to be experiencing something of a philosophical clash with regard
to deprecation. Perhaps we should attempt to establish some general
guidelines for deprecation as a group?

--Kris

6 years ago by Stanislav Malyshev — view source — reply

unread

Hi!

We seem to be experiencing something of a philosophical clash with regard
to deprecation. Perhaps we should attempt to establish some general
guidelines for deprecation as a group?

I personally thought we had thom - no removing things unless there's a
very good reason to. And yet, we have proposals for removing things for
reasons like "it can be done in other ways" and "it requires me to read
the manual to know about all options and variables".

--
Stas Malyshev
smalyshev@gmail.com

6 years ago by Lynn — view source — reply

unread

Hi!

We seem to be experiencing something of a philosophical clash with regard
to deprecation. Perhaps we should attempt to establish some general
guidelines for deprecation as a group?

I personally thought we had thom - no removing things unless there's a
very good reason to. And yet, we have proposals for removing things for
reasons like "it can be done in other ways" and "it requires me to read
the manual to know about all options and variables".

--
Stas Malyshev
smalyshev@gmail.com

--

Hi,

I think it's best to discuss this in a new thread. This way the RFC thread
can stay about this RFC.

Regards,
Lynn van der Berg

6 years ago by Mark Randall — view source — reply

unread

I personally thought we had thom - no removing things unless there's a
very good reason to.

Hi Stanislav,

It has yet to be determined if there's a consensus on if the arguments
given in favour of deprecation represent a good enough reason for the BC
change.

That is the purpose of the eventual vote, is it not? To allow the
community to make that determination.

Regardless of the outcome of this specific RFC, I am of the firm belief
that it's important to be able to re-visit past choices every now and
then. That applies to most things, not just PHP.

--
Mark Randall

6 years ago by Stanislav Malyshev — view source — reply

unread

Hi!

That is the purpose of the eventual vote, is it not? To allow the
community to make that determination.

Not exactly - there should be a good reason before the RFC comes to a
vote. If you're not sure there's a VERY good reason, there shouldn't be
the RFC about it at all, at least not in voting phase. RFC process
shouldn't be just "let's throw it against the wall and see if anything
sticks", it should be used responsibly.

Regardless of the outcome of this specific RFC, I am of the firm belief
that it's important to be able to re-visit past choices every now and
then. That applies to most things, not just PHP.

In abstract, this a banality, yes, it is important, sometimes. In
specific, I've seen a torrent of BC-breaking proposals lately that seem
to have no good reason except for removing stuff because... I'm not even
sure because of what, most of it seems to be vague stuff like
"unintuitive" and "you can do it in other way". I think effort spent on
breaking BC without a VERY good reason is a wasted effort. Having as
little syntax constructs and functions as absolutely possible has never
been the goal of PHP, and I am surprised why it is in fashion now.

Stas Malyshev
smalyshev@gmail.com

6 years ago by Olumide Samson — view source — reply

unread

Hi!

That is the purpose of the eventual vote, is it not? To allow the
community to make that determination.

Not exactly - there should be a good reason before the RFC comes to a
vote. If you're not sure there's a VERY good reason, there shouldn't be
the RFC about it at all, at least not in voting phase. RFC process
shouldn't be just "let's throw it against the wall and see if anything
sticks", it should be used responsibly.

Regardless of the outcome of this specific RFC, I am of the firm belief
that it's important to be able to re-visit past choices every now and
then. That applies to most things, not just PHP.

In abstract, this a banality, yes, it is important, sometimes. In
specific, I've seen a torrent of BC-breaking proposals lately that seem
to have no good reason except for removing stuff because... I'm not even
sure because of what, most of it seems to be vague stuff like
"unintuitive" and "you can do it in other way". I think effort spent on
breaking BC without a VERY good reason is a wasted effort. Having as
little syntax constructs and functions as absolutely possible has never
been the goal of PHP, and I am surprised why it is in fashion now.

Stas Malyshev
smalyshev@gmail.com

--

What's the goal of PHP?