Den 2019-10-31 kl. 16:48, skrev Claude Pache:
Le 31 oct. 2019 à 15:59, Theodore Brown a écrit :
Of course there will always be an infinite number of logical ways to
structure a program, but this is quite different from having two
different syntaxes in a language that do exactly the same thing
> Le 31 oct. 2019 à 15:59, Theodore Brown a écrit :
>
> Of course there will always be an infinite number of logical ways to
> structure a program, but this is quite different from having two
> different syntaxes in a language that do exactly the same thing. The
> latter is confusing since it's
On Tue, Oct 8, 2019 at 6:02 AM Reinis Rozitis wrote:
> Not directly related to this RFC but out of curiosity - where does
> this "doing the same thing in multiple ways is confusing" comes from?
> (I mean this as serious question)
>
> I had the impression that programming in essence is all about t
On Thu, Oct 10, 2019, 4:35 AM Stanislav Malyshev
wrote:
> Hi!
>
> > it into some kind of proxy war. Yes, "it breaks backwards compatibility
> for
> > questionable benefit" is an argument against this proposal, it is even a
> > *very good* argument against it, but it's also no mandate to shut down
Hi!
> it into some kind of proxy war. Yes, "it breaks backwards compatibility for
> questionable benefit" is an argument against this proposal, it is even a
> *very good* argument against it, but it's also no mandate to shut down the
> discussion entirely.
Well, anyone is free to continue the dis
Hello,
I don't understand why people complain about PHP in term of comparison; if
they like more C# or python why don't just
go there?
historically php is a kind of C like dialect with some perlish running thru
an apache-mod giving the opportunity
to break free from the CGI cumbersome world; the
On Wed, Oct 9, 2019 at 12:19 PM Olumide Samson wrote:
>
>
> On Wed, Oct 9, 2019, 3:41 PM Bishop Bettini wrote:
>
>> On Mon, Oct 7, 2019 at 5:21 PM Olumide Samson
>> wrote:
>>
>>> On Mon, Oct 7, 2019, 9:20 PM Claude Pache
>>> wrote:
>>>
>>> > > Le 7 oct. 2019 à 22:06, Olumide Samson a
>>> écri
On Wed, Oct 9, 2019, 3:41 PM Bishop Bettini wrote:
> On Mon, Oct 7, 2019 at 5:21 PM Olumide Samson
> wrote:
>
>> On Mon, Oct 7, 2019, 9:20 PM Claude Pache wrote:
>>
>> > > Le 7 oct. 2019 à 22:06, Olumide Samson a
>> écrit :
>> > >
>> > > What's the goal of PHP?
>> >
>> > One important goal is
On Mon, Oct 7, 2019 at 5:21 PM Olumide Samson wrote:
> On Mon, Oct 7, 2019, 9:20 PM Claude Pache wrote:
>
> > > Le 7 oct. 2019 à 22:06, Olumide Samson a écrit
> :
> > >
> > > What's the goal of PHP?
> >
> > One important goal is (like many programming languages) to get work done.
> >
> I disagr
Hi,
On Tue, Oct 8, 2019 at 11:13 PM Mike Schinkel wrote:
> If a vote is the middle ground then why the need to participate in any
> discussion?
>
> Also, how is a vote a middle ground? A vote ensures that one sides wins
> and the other side looses. IOW, a zero-sum game.
>
> Why does it not make
On Wed, 9 Oct 2019 at 0:38 Mike Schinkel wrote:
> ...it seems you have identified at least one way to seek compromise. Why
> not move forward with this, in general?
>
>
I did - quite a while ago - and I see no reason not to, except that the
pro-strict/pro-let’s-break-things camp either ignores t
On Fri, Oct 4, 2019 at 5:45 PM Mark Randall wrote:
> Hi Internals,
>
> I put forward the following RFC "Deprecate Backtick Operator (V2)" for
> discussion.
>
> https://wiki.php.net/rfc/deprecate-backtickTrying to drag every single
> discussion to the meta level is exactly what is causing these un
On Wed, Oct 9, 2019, 12:59 AM M. W. Moe wrote:
> Hello,
>
> the point Stanislav is really not about whom; that's about thinking, work,
> effort, personal walk thru a problem;
> and I am sorry he is fully right; live example:
>
> "I think that's been inconsistencies from the part of early contribu
Hello,
the point Stanislav is really not about whom; that's about thinking, work,
effort, personal walk thru a problem;
and I am sorry he is fully right; live example:
"I think that's been inconsistencies from the part of early contributors
which is the same reason we are having "haystack and nee
On 09/10/2019 00:26, Stanislav Malyshev wrote:
That's part of the problem. RFC should be for something that is
necessary and beneficial for the whole community, doubly and triply so
when we're talking about BC breaks. It shouldn't be just "whatever I
want, let me put it to a vote". RFCs are not a
On Tue, Oct 8, 2019, at 6:26 PM, Stanislav Malyshev wrote:
> Hi!
>
> > If you feel you want all those functions deprecated in favor of any other,
> > put up a RFC whenever you want to(No one is stopping you from that).
>
> That's part of the problem. RFC should be for something that is
> necessar
Hi!
> If you feel you want all those functions deprecated in favor of any other,
> put up a RFC whenever you want to(No one is stopping you from that).
That's part of the problem. RFC should be for something that is
necessary and beneficial for the whole community, doubly and triply so
when we're
On Tue, Oct 8, 2019, 3:30 PM Chase Peeler wrote:
> On Sun, Oct 6, 2019 at 9:18 AM Reinis Rozitis wrote:
>
> > > -Original Message-
> > > From: Olumide Samson [mailto:oludons...@gmail.com]
> > >
> > > it should be deprecated for exec usage since they both do same thing
> >
> > With that
> On Oct 8, 2019, at 5:34 PM, Zeev Suraski wrote:
> So while I sympathize with the effort to find a compromise - encouraging more
> of these contentious proposals (by accommodating them at some level) is not
> the way.
Ok, but...
> The real middle ground is to go for some form of opt-in soluti
On Tue, 8 Oct 2019 at 22:38 Mike Schinkel wrote:
> > a middle ground about/with silliness? there is none, for people in their
> right mind; should people really find/force
> > themselves into conciliation about non-sense? I don't think so and
> mostly; I have no say about deprecating that;
> > bu
On Tue, Oct 8, 2019 at 2:25 PM M. W. Moe wrote:
> Hello,
>
> what you write and advocate for can't be heard by a vast majority of people
> here; because they are just not North-American; somehow
> that's a very interesting trait; most of people despise `kind` moralism.
>
>
> On Tue, Oct 8, 2019 a
Hello,
what you write and advocate for can't be heard by a vast majority of people
here; because they are just not North-American; somehow
that's a very interesting trait; most of people despise `kind` moralism.
On Tue, Oct 8, 2019 at 2:14 PM Mike Schinkel wrote:
> > On Oct 8, 2019, at 4:29 PM
> On Oct 8, 2019, at 4:29 PM, Lynn wrote:
> My middle ground is a vote, regardless of outcome.
If a vote is the middle ground then why the need to participate in any
discussion?
Also, how is a vote a middle ground? A vote ensures that one sides wins and the
other side looses. IOW, a zero-sum
Hello,
I answered you privately about this kind of false assumptions and
projections. (I have an education)
On Tue, Oct 8, 2019 at 1:38 PM Mike Schinkel wrote:
> > a middle ground about/with silliness? there is none, for people in their
> right mind; should people really find/force
> > themselv
> a middle ground about/with silliness? there is none, for people in their
> right mind; should people really find/force
> themselves into conciliation about non-sense? I don't think so and mostly; I
> have no say about deprecating that;
> but is that a priority? does it harm anyone? someone have
On Tue, Oct 8, 2019 at 10:12 PM Mike Schinkel wrote:
> My, my this is a heated topic.
>
> I am commenting in part because I do not have a dog in this hunt. I am
> okay leaving it, I am okay if it is deprecated. There are other things for
> PHP that I care far more about than this RFC. So...
>
On Tue, Oct 8, 2019 at 1:23 PM M. W. Moe wrote:
> @Mike Schinkel,
>
> a middle ground about/with silliness? there is none, for people in their
> right mind; should people really find/force
> themselves into conciliation about non-sense? I don't think so and mostly;
> I have no say about deprecati
> More generally, people take time in understanding the peculiarities of that
> uncommon feature which is the backtick operator. This is a real cost.
Is this a generally agreed-principle that the PHP community believes is
important?
If so, shouldn't we quantify what the cost is and who would
@Mike Schinkel,
a middle ground about/with silliness? there is none, for people in their
right mind; should people really find/force
themselves into conciliation about non-sense? I don't think so and mostly;
I have no say about deprecating that;
but is that a priority? does it harm anyone? someone
My, my this is a heated topic.
I am commenting in part because I do not have a dog in this hunt. I am okay
leaving it, I am okay if it is deprecated. There are other things for PHP that
I care far more about than this RFC. So...
I am wondering if everyone participating in this discussion wou
On Tue, Oct 8, 2019, 20:48 Stanislav Malyshev wrote:
> Hi!
>
> > I was going to learn c++, but then I came across these weird operators
> >>> and <<. At first I thought they were heredoc, but, that obviously
> > wasn't the case. My next guess is that they were some sort of strict
> > comparison =
> On 9 Oct 2019, at 01:34, Björn Larsson wrote:
>
> Den 2019-10-08 kl. 20:22, skrev Stephen Reay:
>>
>>> On 9 Oct 2019, at 01:08, Björn Larsson wrote:
>>>
>>> Den 2019-10-08 kl. 17:49, skrev Stephen Reay:
> On 8 Oct 2019, at 22:21, Andreas Hennings wrote:
>
> The problem with
Hi!
> I was going to learn c++, but then I came across these weird operators
>>> and <<. At first I thought they were heredoc, but, that obviously
> wasn't the case. My next guess is that they were some sort of strict
> comparison === is more strict than ==, so I figured >> is more strict
> than >
Den 2019-10-08 kl. 20:22, skrev Stephen Reay:
On 9 Oct 2019, at 01:08, Björn Larsson wrote:
Den 2019-10-08 kl. 17:49, skrev Stephen Reay:
On 8 Oct 2019, at 22:21, Andreas Hennings wrote:
The problem with the backtick operator syntax is that it is an obscure
but innocent-looking syntax for
On Tue, Oct 8, 2019 at 2:11 PM Stanislav Malyshev
wrote:
> Hi!
>
> > When evaluating the _unique_ cost of migrating legacy code, it should be
> balanced with the _continual_ cost of keeping the feature. That includes:
> >
> > * People wondering what that strange syntax does, or, worse, mistaking
> On 9 Oct 2019, at 01:08, Björn Larsson wrote:
>
> Den 2019-10-08 kl. 17:49, skrev Stephen Reay:
>>
>>> On 8 Oct 2019, at 22:21, Andreas Hennings wrote:
>>>
>>> The problem with the backtick operator syntax is that it is an obscure
>>> but innocent-looking syntax for something that can hav
Hi!
> PHP to new generations. It IS confusing if PHP has more than one way to do
> one thing, and if one of them is considered better than the other nowadays,
No it's not. At least no more than anything else in life. There's always
alternatives to do something. And PHP has always been a language
Den 2019-10-04 kl. 17:45, skrev Mark Randall:
Hi Internals,
I put forward the following RFC "Deprecate Backtick Operator (V2)" for
discussion.
https://wiki.php.net/rfc/deprecate-backtick-operator-v2
I believe it is at least worth a discussion as to the pros and cons of
deprecating this func
Hi!
> When evaluating the _unique_ cost of migrating legacy code, it should be
> balanced with the _continual_ cost of keeping the feature. That includes:
>
> * People wondering what that strange syntax does, or, worse, mistaking it
> with a variation of string literal.
> * Difficulty to search
Den 2019-10-08 kl. 17:49, skrev Stephen Reay:
On 8 Oct 2019, at 22:21, Andreas Hennings wrote:
The problem with the backtick operator syntax is that it is an obscure
but innocent-looking syntax for something that can have a huge,
perhaps devastating, impact.
It is rare enough in the field (as
> On 8 Oct 2019, at 22:21, Andreas Hennings wrote:
>
> The problem with the backtick operator syntax is that it is an obscure
> but innocent-looking syntax for something that can have a huge,
> perhaps devastating, impact.
> It is rare enough in the field (as far as regular packages and
> appl
The problem with the backtick operator syntax is that it is an obscure
but innocent-looking syntax for something that can have a huge,
perhaps devastating, impact.
It is rare enough in the field (as far as regular packages and
applications are concerned) that you can spend 5 years working with
PHP
On Sun, Oct 6, 2019 at 9:18 AM Reinis Rozitis wrote:
> > -Original Message-
> > From: Olumide Samson [mailto:oludons...@gmail.com]
> >
> > it should be deprecated for exec usage since they both do same thing
>
> With that logic does the same thing and is hard to find in internet search
Hello,
would say intellectually speaking I could accept the argument of
time\investment\code however
in reality figuring out for someone having a minimum of shell experience in
that case, would figure
out in 5 minutes if he is very slow minded; none the less, learning new
features, new apis, tha
> Le 8 oct. 2019 à 12:24, Reindl Harald (privat) a écrit :
>
>
>
> Am 08.10.19 um 11:00 schrieb Claude Pache:
>> * People trying to deactivate functions executing external programs (such as
>> `shell_exec`) using the "disable_function" ini directive, wondering how to
>> deactivate the back
On Fri, 2019-10-04 at 16:45 +0100, Mark Randall wrote:
> Hi Internals,
>
> I put forward the following RFC "Deprecate Backtick Operator (V2)"
> for
> discussion.
>
I use them from time to time when using PHP as a better shell scripting
language. Quite useful in that context. Deprecating them m
> -Original Message-
> From: Benjamin Morel [mailto:benjamin.mo...@gmail.com]
>
> One gain that's very often overlooked on this list, is teaching a better PHP
> to
> new generations. It IS confusing if PHP has more than one way to do one thing,
Not directly related to this RFC but out of
Den 2019-10-08 kl. 12:24, skrev Christoph M. Becker:
On 08.10.2019 at 11:44, Björn Larsson wrote:
Den 2019-10-08 kl. 11:00, skrev Claude Pache:
When evaluating the _unique_ cost of migrating legacy code, it should
be balanced with the _continual_ cost of keeping the feature. That
includes:
*
On 08.10.2019 at 11:44, Björn Larsson wrote:
> Den 2019-10-08 kl. 11:00, skrev Claude Pache:
>
>> When evaluating the _unique_ cost of migrating legacy code, it should
>> be balanced with the _continual_ cost of keeping the feature. That
>> includes:
>>
>> * People wondering what that strange synt
> Le 8 oct. 2019 à 11:44, Björn Larsson a écrit :
>
> Den 2019-10-08 kl. 11:00, skrev Claude Pache:
>>> Le 8 oct. 2019 à 10:26, Björn Larsson a écrit :
>>>
>>> Den 2019-10-06 kl. 15:41, skrev Mark Randall:
On 06/10/2019 14:18, Reinis Rozitis wrote:
> Since `` are used for literal st
Den 2019-10-08 kl. 11:00, skrev Claude Pache:
Le 8 oct. 2019 à 10:26, Björn Larsson a écrit :
Den 2019-10-06 kl. 15:41, skrev Mark Randall:
On 06/10/2019 14:18, Reinis Rozitis wrote:
Since `` are used for literal strings (for poorly chosen reserved words as
field, table names (which happens
> Which is why ANY unnecessary changes that need to be made as a
> result are just painful often without ANY gain what so ever on either
side?
One gain that's very often overlooked on this list, is teaching a better
PHP to new generations. It IS confusing if PHP has more than one way to do
one thi
> Le 8 oct. 2019 à 10:26, Björn Larsson a écrit :
>
> Den 2019-10-06 kl. 15:41, skrev Mark Randall:
>> On 06/10/2019 14:18, Reinis Rozitis wrote:
>>> Since `` are used for literal strings (for poorly chosen reserved words as
>>> field, table names (which happens from time to time)) in MySQL (
On 08/10/2019 04:31, Theodore Brown wrote:
In 8 of these, the backtick uses are exclusively in test files or other
scripts not part of the library source code. Then there are 11 packages
with one or two uses each, and only 2 packages with more than two occurrences.
Raw numbers:https://gist.githu
Before replying (quickly) to this, I want to point out, again, that it’s
mind boggling we have to start discussing non-topics and spend time, energy
and mental strength on this endless stream of out-of-the-blue deprecation
proposals.
On Tue, 8 Oct 2019 at 5:32 Theodore Brown wrote:
>
> I did som
Den 2019-10-06 kl. 15:41, skrev Mark Randall:
On 06/10/2019 14:18, Reinis Rozitis wrote:
Since `` are used for literal strings (for poorly chosen reserved
words as field, table names (which happens from time to time)) in
MySQL (multiline) queries I doubt there is a simple way to
distinguish an
On Mon, Oct 7, 2019 at 2:50 AM Nikita Popov wrote:
> On Fri, Oct 4, 2019 at 5:45 PM Mark Randall wrote:
>
> > Hi Internals,
> >
> > I put forward the following RFC "Deprecate Backtick Operator (V2)" for
> > discussion.
> >
> > https://wiki.php.net/rfc/deprecate-backtick-operator-v2
> >
> > I be
On Mon, Oct 7, 2019, 9:20 PM Claude Pache wrote:
>
> > Le 7 oct. 2019 à 22:06, Olumide Samson a écrit :
> >
> >
> > What's the goal of PHP?
>
> One important goal is (like many programming languages) to get work done.
>
> —Claude
>
I disagree, coz this seems to be a goal cooked up by you(even if
> Le 7 oct. 2019 à 22:06, Olumide Samson a écrit :
>
>
> What's the goal of PHP?
One important goal is (like many programming languages) to get work done.
—Claude
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Mon, Oct 7, 2019, 7:53 PM Stanislav Malyshev wrote:
> 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 r
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 vo
> -Original Message-
> From: Mark Randall [mailto:marand...@php.net]
>
> On 06/10/2019 14:18, Reinis Rozitis wrote:
> > Since `` are used for literal strings (for poorly chosen reserved words as
> > field,
> table names (which happens from time to time)) in MySQL (multiline) queries I
> d
On 07/10/2019 07:22, Stanislav Malyshev wrote:
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 th
On Fri, Oct 4, 2019 at 5:45 PM Mark Randall wrote:
> Hi Internals,
>
> I put forward the following RFC "Deprecate Backtick Operator (V2)" for
> discussion.
>
> https://wiki.php.net/rfc/deprecate-backtick-operator-v2
>
> I believe it is at least worth a discussion as to the pros and cons of
> depr
On Mon, Oct 7, 2019, 08:22 Stanislav Malyshev wrote:
> 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
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 h
On Sun, Oct 6, 2019 at 12:36 PM Zeev Suraski wrote:
> On Fri, 4 Oct 2019 at 17:45 Mark Randall wrote:
>
> > 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 tr
On Fri, 4 Oct 2019 at 17:45 Mark Randall wrote:
> 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 l
On 06/10/2019 14:18, Reinis Rozitis wrote:
Since `` are used for literal strings (for poorly chosen reserved words as
field, table names (which happens from time to time)) in MySQL (multiline)
queries I doubt there is a simple way to distinguish and replace everything to
exec().
Hi,
As the
> -Original Message-
> From: Olumide Samson [mailto:oludons...@gmail.com]
>
> it should be deprecated for exec usage since they both do same thing
With that logic This isn't high cost breaking changes coz it has a verifiable, ready
> alternative to upgrade to without huge Regex search
Hi!
> On 6 Oct 2019, at 02:44, Stanislav Malyshev wrote:
>
> Hi!
>
>> Like I said, I can see arguments both ways, but use as a command
>> substitution operator is hardly a universal thing.
>
> Nobody said it's "universal thing”.
I never claimed anyone said it’s universal. I simply said it i
do you think because it's short you'll lose your virginity. I am sorry
about the vulgarity; but your stand is stand is ridiculous.
On Sat, Oct 5, 2019 at 4:04 PM Olumide Samson wrote:
> I think something that deals with system commands should be highly obvious
> and should not be allowed through
I think something that deals with system commands should be highly obvious
and should not be allowed through shortcut syntax that made it easy to be
hidden amongst codes for many security reasons.
There's already a popular way without hidden syntax and which speaks of
itself in a verifiable way ca
The first time I saw the backtick operator in code, I thought it must
be some kind of ancient alternative syntax for string literals.
(and no, I did not know that these are called "backticks")
When I learned that code "quoted" in this way is immediately executed
as shell commands, this seemed like
> Hi!
>
> > This is true, if you know they are called a backtick. It's not a
>
> I think it's reasonable to expect some minimal level of knowledge from
> the user. We're not targeting infants in the kindergarten here. So while
> we aim to not present too many obstacles to the novice user, we can
>
Hi!
> This is true, if you know they are called a backtick. It's not a
I think it's reasonable to expect some minimal level of knowledge from
the user. We're not targeting infants in the kindergarten here. So while
we aim to not present too many obstacles to the novice user, we can
reasonably exp
Hi!
> Like I said, I can see arguments both ways, but use as a command substitution
> operator is hardly a universal thing.
Nobody said it's "universal thing". Virtually nothing is "universal
thing" among over 9000 programming languages that exist. I just claimed
it's a common thing which reason
Hi,
Am 04.10.2019 um 17:45 schrieb Mark Randall:
Hi Internals,
I put forward the following RFC "Deprecate Backtick Operator (V2)" for
discussion.
https://wiki.php.net/rfc/deprecate-backtick-operator-v2
I believe it is at least worth a discussion as to the pros and cons of
deprecating this
> On 5 Oct 2019, at 11:34, Stanislav Malyshev wrote:
>
> Hi!
>
>> https://wiki.php.net/rfc/deprecate-backtick-operator-v2
>
> Reading the justifications, I must say I do not find them very
> convincing. Specifically:
>
>> * Alternative functions exist which are more descriptive, easily
> un
Hi,
> * Alternative functions exist which are more descriptive, easily
> understood, and more readily searchable (for example, many common Google
> searches omit the “`” token entirely when searching).
>
> It is very easy to understand `` since it has analogues in other script
languages, also sea
Hi!
> https://wiki.php.net/rfc/deprecate-backtick-operator-v2
Reading the justifications, I must say I do not find them very
convincing. Specifically:
> * Alternative functions exist which are more descriptive, easily
understood, and more readily searchable (for example, many common Google
searc
On 04/10/2019 19:03, Sara Golemon wrote:
The argument about it not being obvious that exec related ini settings
apply to backtick is silly and I'm going to ignore it.
I have updated the RFC to note that the reason for this potential
confusion is that that during compilation, rather than just h
On Fri, Oct 4, 2019 at 10:45 AM Mark Randall wrote:
> I put forward the following RFC "Deprecate Backtick Operator (V2)" for
> discussion.
>
> https://wiki.php.net/rfc/deprecate-backtick-operator-v2
>
> The argument that they're visually difficult to distinguish from a single
quote is valid (thou
83 matches
Mail list logo
