> On 3 Jul 2020, at 13:27, Nikita Popov wrote:
>
> Now, whether this RFC actually makes a sufficient case to disregard policy
> here is a different question, and at the discretion of the voters.
I think this is key here (the first part, not the second).
It doesn’t seem as if the RFC makes any
On 11 Jun 2020, at 12:07, Sebastian Bergmann wrote:
Am 11.06.2020 um 00:13 schrieb Sara Golemon:
Token names shouldn't show up. Everyone is agreeing with that statement.
Universally. Let's fix that problem rather than create new ones by not
addressing the underlying issue.
+1
+1
Zeev
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 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
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
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 Wed, 2 Oct 2019 at 15:24 Nikita Popov wrote:
>
> * The "Undefined array index" case. This one passed the vote with an exact
> 2/3 majority, so I'm a bit uncomfortable making changes here.
I think that making this change on the edge of a single vote is less than
ideal... Even if I’m known
On Fri, Sep 20, 2019 at 12:52 PM Zeev Suraski wrote:
>
> Speaking of 'disruptive behavior' that the antithesis of promoting 'good
> will' - this pseudo RFC is a textbook example.
>
I wrote an analysis of this outlandish proposal that I hope some may find
u
On Sat, Sep 21, 2019 at 6:18 PM Kosit Supanyo
wrote:
> Unlike var, public, static and others - 'global' is not a declaration of
>> class structure, but a way to access global variables.
>
>
> I know it is not and I think almost everyone knows that. As I said, I came
> up with this by comparing to
On Sat, Sep 21, 2019 at 3:09 PM Kosit Supanyo
wrote:
> I understand your point but inconsistency in my sense is syntactical By
> comparing to other declaration syntax like `var`, `static`, 'public` an
> others. They allow only T_VARIABLE but `global` is different. And there's
> another way to arc
On Fri, Sep 20, 2019 at 2:24 PM Benjamin Eberlei
wrote:
>
>
> On Fri, Sep 20, 2019 at 11:53 AM Zeev Suraski wrote:
> This style of conversation has regularly lead to contributors that don't
> want the intensity quit contributing silently. It is not healthy for this
> comm
Andreas, all,
Speaking of 'disruptive behavior' that the antithesis of promoting 'good
will' - this pseudo RFC is a textbook example.
But some of the responses on the thread are actually more interesting and
nicely written and do warrant a response.
On Fri, Sep 20, 2019 at 10:14 AM Andreas Heigl
On Thu, Sep 19, 2019 at 1:44 AM Olumide Samson wrote:
> I've been following closely lately and have seen you(Zeev Suraski)
> question *RFC authority*(what it was meant for or not, even though your
> facts weren't written as facts anywhere).
>
You've questioned the
On Wed, Sep 18, 2019 at 8:33 PM Dan Ackroyd wrote:
> # Problem 3 - Newcomers to the mailing list aren't following our
> etiquette.
# Problem 4 - Senior project members aren't following our email etiquette.
This too isn't directed so much at Dan, but rather the list at large.
Some facts about
On Tue, Sep 17, 2019 at 3:32 PM Larry Garfield
wrote:
> Simple question for those that keep arguing that the RFC process is only
> applicable to a certain subset of issues:
>
> OK, so what's the alternative?
>
> If we wanted to make a structural or governance change to PHP, what is the
> process?
On Mon, Sep 16, 2019 at 1:18 PM Benjamin Eberlei
wrote:
>
> We heard you repeating the RFC process isn't applicable very often now,
> but a productive way forward needs to take it into account to make any
> change in governance.
>
I think it can actually be taken into account. As I wrote - we c
This note isn't really for Joe, who will likely would not pay too much if
any attention to whatever I or whomever else who disagrees with his
position on the universal applicability of the Voting RFC in its current
form has to say.
This is for the many other folks following this and other threads.
I think it's clear you don't realize how rude you are, no surprises there.
I'm not going to continue discussing this topic with you. You seem to
think my words carry no weight, I'm absolutely sure yours don't carry any
weight - let's save everyone some time mental strain.
To everyone else - I sta
On Sun, Sep 15, 2019 at 2:37 PM Peter Bowyer
wrote:
> On Sun, 15 Sep 2019 at 06:48, Joe Watkins wrote:
>
> > The Wikipedia states that PHP is developed by the PHP Group, in saying
> this
> > it is (must be) referring to internals as a whole, but our own
> > documentation names members of the gro
On Sun, Sep 15, 2019 at 1:15 PM Olumide Samson wrote:
> I also don't agree with the index and all its statistics
>
I'm not sure what you mean by 'all its statistics'. Mostly everything on
the methodology page is fluff, which may be purposely there to hide the
only part that really matters:
On Sun, Sep 15, 2019 at 6:33 AM Mike Schinkel
wrote:
> > On Sep 14, 2019, at 5:18 PM, Olumide Samson
> wrote:
> >
> > https://jaxenter.com/php-tiobe-sept-2019-162096.html
> > I think this is one of those things we get from voting no...
> >
> > I might be wrong anyways :-?
>
First of all, Olumid
On Fri, Sep 13, 2019 at 11:59 AM Olumide Samson
wrote:
> "We know it is bad or can be devastating
Actually, that's not at all what we're saying.
I think that doing something like @$foo++ is absolutely fine. Many others
on this (and related) threads think so too. I find all the 'improvements'
> On 13 Sep 2019, at 2:50, Joe Watkins wrote:
>
> Zeev,
>
> > Without getting to the technicalities, simply put, no.
>
> I'm not sure what you intend to do to stop it.
I sincerely hope reason will prevail and we won't have to find out (as I was
hoping this part of the RFC won't be put up for
On 13 Sep 2019, at 2:21, Joe Watkins
mailto:krak...@gmail.com>> wrote:
Zeev,
I'm going to keep this really short and simple ...
I'll do the same.
You don't have the authority to make unilateral decisions for PHP,.
Neither does anybody else on this list. Not even a plurality or a majority o
On Fri, Sep 13, 2019 at 12:35 AM Lynn wrote:
> On Thu, Sep 12, 2019 at 10:58 PM Peter Bowyer
> wrote:
>
> >
> > One can argue that WordPress, with it powering 34% of the web (source:
> > wordpress.org) represents more than 50% of PHP users, and therefore
> > aligning the language to how they use
On Fri, Sep 13, 2019 at 12:00 AM Alexandru Pătrănescu
wrote:
> Also, I would also like to remind of this:
> https://github.com/php/php-src/blob/master/docs/mailinglist-rules.md
> I think some parts might have been violated multiple time in this thread.
As was already pointed out in a different
On Thu, Sep 12, 2019 at 7:39 PM Andreas Heigl wrote:
>
>
> > You may be wondering, in that case, what processes do we have to deal
> with
> > such changes then? The answer is simple. We don't. We don't have to
> have
> > them either - the fundamental language behaviors are here to stay.
>
> Bu
> -Original Message-
> From: Olumide Samson
> Sent: Thursday, September 12, 2019 6:03 PM
> To: Dan Ackroyd
> Cc: Zeev Suraski ; PHP internals
> Subject: Re: [PHP-DEV] Changing fundamental language behaviors
>
> The RFC is Request for Comment on any changes,
> -Original Message-
> From: Marco Pivetta
> Sent: Thursday, September 12, 2019 5:59 PM
> To: Zeev Suraski
> Cc: PHP Internals List
> Subject: Re: [PHP-DEV] Changing fundamental language behaviors
>
> If you want to have an authoritative say on what the RFC
I was really really hoping that we will avert having to dive into this and
instead go for the alternative solution that was proposed of changing
default php.ini error levels. But since the RFC went on to a vote - we need
to make something clear.
The RFC process was never, ever meant to handle
> On 30 Aug 2019, at 12:33, Nikita Popov wrote:
>
> Hi internals,
>
> Relating to the recent discussions on undefined variables & co. One thing
> that is particularly annoying about the undefined variable case is that our
> default error_reporting level (without a php.ini) does not include E_N
> On 30 Aug 2019, at 12:33, Nikita Popov wrote:
>
> Hi internals,
>
> Relating to the recent discussions on undefined variables & co. One thing
> that is particularly annoying about the undefined variable case is that our
> default error_reporting level (without a php.ini) does not include E_N
On Thu, Aug 29, 2019 at 3:48 PM Alexandru Pătrănescu
wrote:
> Zeev, you might not agree with rules and hints but I strongly believe that
> they are great rules.
>
I think many of them are great (such as not posting when agitated, thinking
about what you want to say, being respectful, etc.), and
On Thu, Aug 29, 2019 at 4:02 PM Aegir Leet via internals <
internals@lists.php.net> wrote:
> I know what the manual says about notices. But I don't agree with
> interpreting "could happen in the normal course of running a script" as
> "it's perfectly fine if this part of your code triggers a notic
On Thu, Aug 29, 2019 at 10:43 AM Nikita Popov wrote:
> Hi internals,
>
> A gentle reminder to everyone that this mailing list has rules, documented
> at https://github.com/php/php-src/blob/master/docs/mailinglist-rules.md.
> In
> particular:
>
And a gentle reminder that these are guidelines (eve
On Wed, Aug 28, 2019 at 10:28 PM Matthew Brown
wrote:
> Javascript has treated undefined variables as a catchable exceptions since
> (I think?) forever. Perl is the only other language I know that allows them.
>
That isn't the point (I alluded to the fact that JS dealt with something
*similar* b
On Wed, Aug 28, 2019 at 10:26 PM Nikita Popov wrote:
> On Wed, Aug 28, 2019 at 11:33 AM Nikita Popov
> wrote:
>
> Reading this discussion has been disappointing and somewhat disillusioning.
> I can understand and appreciate the concern for legacy code. But seeing the
> use of undefined variables
On Wed, Aug 28, 2019 at 8:20 PM Matthew Brown
wrote:
> We log 1 in every 1000 notices, and yes - being notice-free is a goal –
> though not one with any particular timeline at the moment, because we can
> just ignore the problem. I look forward to not being able to ignore the
> problem.
When wa
On Wed, Aug 28, 2019 at 5:22 PM Matthew Brown
wrote:
> Looking at our notice logs, I estimate (fairly roughly) that it would
> require about a week's worth of my time to fix these issues in vimeo.com’s
> 700K LOC codebase (the undefined variables are confined to our views).
>
Can you elaborate a
On Wed, Aug 28, 2019 at 2:10 PM Nikita Popov wrote:
> On Wed, Aug 28, 2019 at 12:41 PM Zeev Suraski wrote:
>
>>
>>
>> On Wed, Aug 28, 2019 at 12:33 PM Nikita Popov
>> wrote:
>>
>>> Hi internals,
>>>
>>> I think it's time to
On Wed, Aug 28, 2019 at 12:33 PM Nikita Popov wrote:
> Hi internals,
>
> I think it's time to take a look at our existing warnings & notices in the
> engine, and think about whether their current classification is still
> appropriate. Error conditions like "undefined variable" only generating a
>
On 23 Aug 2019, at 10:56, Zeev Suraski mailto:z...@zend.com>>
wrote:
On 23 Aug 2019, at 10:33, Nikita Popov
mailto:nikita@gmail.com>> wrote:
Hi internals,
We currently have separate karma for the Zend/TSRM directories in php-src.
I think this separation has become more a
> On 23 Aug 2019, at 10:33, Nikita Popov wrote:
>
> Hi internals,
>
> We currently have separate karma for the Zend/TSRM directories in php-src.
> I think this separation has become more annoying than useful at this point.
> Most changes from newer contributors are approved on GitHub first, a
I'm on vacation so only at a high level:
- If it's anything remotely similar to the one for P++ (abrupt, done without
any coordination with the author, goes into a vote with immediate effect,
grossly misrepresents the idea while refusing to fix that even after the fact,
pretends to be an RFC ev
I did not intent to write anything else in this thread, but since someone
reverted the edits I made to fix the description of the P++ idea in the
poll, I have to.
One of the many ways in which this poll was problematic is that it
substantially misrepresents the idea - while claiming that this is i
On Wed, Aug 14, 2019 at 6:14 PM Derick Rethans wrote:
> Hi,
>
> In the last week(s) there has been a lot of chat about Zeev's P++ idea.
> Before we end up spending this project's time and energy to explore this
> idea further, I thought it'd be wise to see if there is enough animo for
> this. Hen
On Mon, Aug 12, 2019 at 2:56 PM Arnold Daniels
wrote:
> I've added a list of concerns to the FAQ. These are both taken from the
> discussion as well as concerns I have myself.
>
Along the lines of the 'counterpoint' to short tags, I moved the concerns
into a separate page here: http://wiki.php.
On Sat, Aug 10, 2019 at 6:21 PM guilhermebla...@gmail.com <
guilhermebla...@gmail.com> wrote:
> 1- How would you envision a shared runtime between PHP and P++, in the
> case that this new evolved solution decides to support objects as keys
> in array structure? This fundamentally changes internals
On Sat, Aug 10, 2019 at 12:37 PM Andrea Faulds wrote:
> Hi Zeev,
>
> As the person who initially proposed and implemented strict_types, I
> think this is heading in the wrong direction. Perhaps that directive was
> a mistake, if it will lead to so many attempts inspired by it to
> fragment the la
On 10 Aug 2019, at 1:51, Sara Golemon mailto:poll...@php.net>>
wrote:
On Fri, Aug 9, 2019 at 4:58 PM Zeev Suraski mailto:z...@php.net>>
wrote:
As Bob pointed out I'm rusty, but I do think that we can solve the short
tags issue in this way. At the lexer level, if we see
On Sat, Aug 10, 2019 at 12:03 AM Sara Golemon wrote:
> On Fri, Aug 9, 2019 at 2:54 PM Zeev Suraski wrote:
>
> > It's available here: https://wiki.php.net/pplusplus/faq
> >
> >
> It's possible I missed something while on holiday. There are certainly a
>
On Fri, Aug 9, 2019 at 11:27 PM Mark Randall wrote:
> On 09/08/2019 20:54, Zeev Suraski wrote:
> > It's available here: https://wiki.php.net/pplusplus/faq
>
> I am now even more confused.
>
> How is this drastically different to Nikita's suggestion of setting a
&
Bob,
I appreciate your candid email. Please see responses below.
On Fri, Aug 9, 2019 at 11:12 PM Bob Weinand wrote:
> It's clearly quite a feat, your contributions to PHP 3 and PHP 4.
> This does not give you any authority now.
While I completely disagree, that is completely beside the point
During the discussion of the P++ proposal (
https://externals.io/message/106453), it became painfully clear that this
idea did little, so far, to bring peace to the galaxy.
However, based on a lot of the feedback, both on internals@ and elsewhere -
it seems that a lot of people simply didn't reall
On Fri, Aug 9, 2019 at 7:44 PM Dan Ackroyd wrote:
> On Fri, 9 Aug 2019 at 17:10, Zeev Suraski wrote:
> >
> > we’re discussing whether it makes sense to introduce a sister language
> to PHP.
>
> Zeev also wrote:
> > It will take no additional resources,
>
Sent from my tablet
> On 9 Aug 2019, at 19:02, Mark Randall wrote:
>
>> On 09/08/2019 08:15, Zeev Suraski wrote:
>> You seem to believe that C++ is inherently superior to C. And it's
>> entirely within your right.
>> However, there are projects - to thi
On Fri, Aug 9, 2019 at 4:12 PM Dan Ackroyd wrote:
> On Thu, 8 Aug 2019 at 21:17, Zeev Suraski wrote:
> >
> > My goal is to have two sister languages, with both PHP and P++
> > being equal among equals
>
> PHP internals is already lacking programming resources to do
On Fri, Aug 9, 2019 at 10:22 AM Nikita Popov wrote:
> On Thu, Aug 8, 2019 at 11:25 PM Zeev Suraski wrote:
>
> I think this part is unrealistic from a simple manpower perspective. We
> have something like ~2 full time developers working on PHP. Even if you can
> rally some addi
On Fri, Aug 9, 2019 at 3:43 PM Michał Brzuchalski <
michal.brzuchal...@gmail.com> wrote:
> I've got an impression that you're the only one who sees a good direction
> in splitting the language in two different dialects and am not sure about
> sincere intentions.
>
This isn't splitting the languag
On Fri, Aug 9, 2019 at 1:44 PM Robert Korulczyk wrote:
> > I think it should also be pointed out that there's nothing stopping
> anyone
> > from forking PHP into a new project as Zeev described and maintain
> feature
> > parity. As I understand, the reason something like this hasn't happened
> >
On Fri, Aug 9, 2019 at 11:15 AM Michał Brzuchalski <
michal.brzuchal...@gmail.com> wrote:
> Hi Sergey,
>
> pt., 9 sie 2019, 09:40 użytkownik Sergey Panteleev
> napisał:
>
> > As I understand, in P++ it was planned to drop the legacy code, add new
> > functionality and painlessly implement BC.
> >
On Fri, Aug 9, 2019 at 10:40 AM Sergey Panteleev
wrote:
> As I understand, in P++ it was planned to drop the legacy code,
Correct.
> add new functionality
Correct.
> and painlessly implement BC.
>
Probably correct - but to phrase it more accurately - when we introduce P++
- we won't be bo
do not need to have the
> same BC concerns as regular PHP. Should we make a horrible mistake in some
> edition, we don't need to take 10 years to fix it, we may even fix it in
> the very next edition.
>
> Cheers
> Joe
>
>
>
>
>
>
>
> On Fri, 9 Aug 2
On Fri, Aug 9, 2019 at 2:53 AM Mark Randall wrote:
> On 09/08/2019 00:08, Zeev Suraski wrote:
> > 2. Different people have different preferences. There's a reason that
> not
> > everyone is using the same language, or have the same mobile phone or the
> > same car.
On Fri, Aug 9, 2019 at 1:25 AM Mark Randall wrote:
> On 08/08/2019 21:17, Zeev Suraski wrote:
> > [... and not in the Sith Lord kind of way.]
> > Thoughts?
>
> The idea of PHP being held hostage to eternal backwards compatibility
> fills me with absolute dread.
>
[s
On Fri, Aug 9, 2019 at 12:22 AM Nikita Popov wrote:
> On Thu, Aug 8, 2019 at 11:02 PM Nikita Popov wrote:
>
>> On Thu, Aug 8, 2019 at 10:17 PM Zeev Suraski wrote:
>>
>> This is basically what I have been advocating for a while now already,
>> somewhat hidden betw
On Fri, Aug 9, 2019 at 12:02 AM Nikita Popov wrote:
> This is basically what I have been advocating for a while now already,
> somewhat hidden between all the other noise of the "namespace-scoped
> declares" thread. The model I would like to follow are Rust editions (
> https://doc.rust-lang.org/
[... and not in the Sith Lord kind of way.]
Looking at some of the recent (& not so recent) discussions on internals@,
some of the recent proposals, as well as some of the statements made
regarding the future direction of the language - makes it fairly clear that
we have a growing sense of polariz
On Thu, Aug 8, 2019 at 10:35 PM Zeev Suraski wrote:
>
>
> On Thu, Aug 8, 2019 at 9:10 PM Bishop Bettini wrote:
>
>> On Tue, Aug 6, 2019 at 7:34 AM G. P. B. wrote:
>>
>> > The voting for the "Deprecate short open tags, again" [1] RFC has begun.
>
On Thu, Aug 8, 2019 at 9:10 PM Bishop Bettini wrote:
> On Tue, Aug 6, 2019 at 7:34 AM G. P. B. wrote:
>
> > The voting for the "Deprecate short open tags, again" [1] RFC has begun.
> > It is expected to last two (2) weeks until 2019-08-20.
> >
> > A counter argument to this RFC is available at
>
On Thu, Aug 8, 2019 at 3:17 PM Brent wrote:
> I asked similar questions on Twitter, where Zeev replied the following:
> https://mobile.twitter.com/zeevs/status/115865658046464
I want to add a bit of color to this tweet:
- Estimated # of developers using PHP is at around 10M. This is based
On Thu, Aug 8, 2019 at 12:39 AM Peter Kokot wrote:
> Thank you for such a detailed response. Ok, I understand then. Then
> next logical step here is - I would maybe want to use these awesome
> short tags also then.
No disrespect Peter, but I really don't think you understand (my position).
I d
On Wed, Aug 7, 2019 at 8:45 PM Peter Kokot wrote:
> Considering that you're in favor of keeping the short opening tag in
>
PHP "forever" because you haven't added any kind of other solution
> either by now neither you see an issue with this... I think the worst
> situation for language is that th
On Wed, Aug 7, 2019 at 4:56 PM Dan Ackroyd wrote:
> On Wed, 7 Aug 2019 at 09:45, Peter Kokot wrote:
> >
> > Yes, last time I was asking this, there was a clarification that
> > certain people from the group internals can veto particular RFC.
>
> Please could you point to where this alleged rule
On 7 Aug 2019, at 12:39, Christoph M. Becker
mailto:cmbecke...@gmx.de>> wrote:
As I understand it, this RFC has been put to vote again, because the first
version had some problematic details, and by courtesy to cater to the clamor
raised after
the voting had finished.
That is correct. There
> On 6 Aug 2019, at 21:46, Nikita Popov wrote:
>
>> On Tue, Aug 6, 2019 at 1:34 PM G. P. B. wrote:
>>
>> The voting for the "Deprecate short open tags, again" [1] RFC has begun.
>> It is expected to last two (2) weeks until 2019-08-20.
>>
>> A counter argument to this RFC is available at
>>
On Mon, Aug 5, 2019 at 10:05 PM G. P. B. wrote:
>
> I'd prefer Dan's approach and having a seperate page linked at the top of
> the RFC.
>
> I'll start voting tomorrow and will link to your page in the same message
> as the voting announcement.
>
Thanks George. I created a page with a counterar
As we head closer to the vote - and in light of what I said towards the end
of my message in https://externals.io/message/106256#106278, as well as the
points Dan articulated regarding the current issue of negative feedback not
getting the same level of visibility as the RFC itself - I'd like to fi
>
>
> On Mon, Aug 5, 2019 at 4:34 PM Dan Ackroyd wrote:
> So, recently there was some discussion about RFCs that have passed
> despite there being some strong objections to them.
>
> I think there is a fundamental problem that could be addressed here,
> in that the arguments 'for' an RFC have muc
On Wed, Jul 31, 2019 at 5:09 PM guilhermebla...@gmail.com <
guilhermebla...@gmail.com> wrote:
> threat /THret/ noun: a statement of an intention to inflict pain,
> injury, damage, or other hostile action on someone in retribution for
> something done or not done.
>
Exactly. If making people stic
On Wed, Jul 31, 2019 at 4:31 PM Dan Ackroyd wrote:
> On Wed, 31 Jul 2019 at 09:50, Zeev Suraski wrote:
> >
> > This was not a threat of any kind,
>
> "If we need to pull rank with group@ here, we will."
>
> "I'm confident that if it ever came to th
I believe I addressed most of what you wrote in my reply to Nikita, except
for this:
On Tue, Jul 30, 2019 at 10:45 PM Dan Ackroyd wrote:
> On Tue, 30 Jul 2019 at 20:09, Zeev Suraski wrote:
> If they do - it's absolutely their responsibility
> > to defend their proposal
>
On Tue, Jul 30, 2019 at 10:37 PM Nikita Popov wrote:
> Zeev,
>
>
Nikita,
Similarly to how I answered Bob, I want to prefix my message with an
off-topic statement that I think is important, albeit obvious.
I think you're a remarkably talented developer that is an invaluable asset
to the PHP proje
On Tue, Jul 30, 2019 at 9:30 PM Bob Weinand wrote:
> > Am 30.07.2019 um 17:14 schrieb Zeev Suraski :
>
> > Zeev
>
Before I answer on point - I'd like to thank you that despite the fact you
clearly disagree with me - you wrote your message in a courteous,
respectful t
On Tue, Jul 30, 2019 at 6:10 PM Levi Morrison
wrote:
> On Mon, Jul 29, 2019, 10:55 PM Zeev Suraski wrote:
>
>
I think ignoring people is totally acceptable behaviour on this list. May I
> remind you that in the not distant past this list was called a toxic
> kindergarten and othe
> I'm sorry Stas, but I will not be reading your mails in the future. I think
> you mean
> well and do raise legitimate points, but I have noticed over a long period of
> time
> that I find arguing with you to be extremely mentally exhaustive, while
> ultimately deriving very little actionable
On Wed, Jul 24, 2019 at 4:27 PM G. P. B. wrote:
> Now if we can all agree that this can land without needing to go through
> this
> whole process I think everybody wins: we all don't need to spend time on
> this,
> it can be merged as it, the RMs could re-tag Beta 1 (which may will need to
> happ
[Had an issue with my email client, apologies if it ends up being sent
twice]
On Tue, Jul 23, 2019 at 8:55 PM G. P. B. wrote:
> Hello internals,
>
> Due to the controversy after the initial vote on the Deprecate PHP's Short
> Open Tag RFC [1] here is a new RFC to deprecate them written with the
On Tue, Jul 16, 2019 at 9:07 AM G. P. B. wrote:
> On Tue, 16 Jul 2019 at 17:00, Zeev Suraski wrote:
>
> > On Tue, Jul 16, 2019 at 7:34 AM G. P. B.
> wrote:
> >
> >> The RFC process establishes a consensus when 2/3 of the voters agree,
> >> which is
On Tue, Jul 16, 2019 at 7:34 AM G. P. B. wrote:
> On Tue, 16 Jul 2019 at 16:18, Zeev Suraski wrote:
>
Secondly the word you are looking for here is "unanimity"/"unanimous" as
> per the Cambridge dictionary [1]:
>
>> *If a group of people are unanimou
Given apparently nobody has paid any attention to this email (both in terms
of my support of deprecating hebrevc(), and my request to reconsider
supporting proposals with substantial numbers of 'nay' voters) - I'm
resending it one more time for consideration:
On Wed, Jul 10, 2019 at 2:33 PM wrote
On Tue, Jul 16, 2019 at 5:34 AM Bishop Bettini wrote:
> On Tue, Jul 16, 2019 at 3:51 AM Nikita Popov wrote:
>
> > On Tue, Jul 16, 2019 at 3:40 AM Arnold Daniels <
> > arnold.adaniels...@gmail.com>
> > wrote:
> >
> > > Hi,
> > >
> > > PHP replaces dots with underscores for $_GET, $_POST and $_COO
On Mon, Jul 8, 2019 at 5:37 PM Nikita Popov wrote:
>
> I'm certainly not a domain expert in RTL languages. I'd be happy to drop
> hebrev() from this RFC if someone can bring forward a good technical
> argument as to why these functions are still necessary and where they would
> be used.
>
I do i
On Mon, Jul 8, 2019 at 4:53 PM Claude Pache wrote:
>
> > Le 8 juil. 2019 à 15:20, Christoph M. Becker a
> écrit :
> >
> > FTR, there is already substr_compare().
>
> `substr_compare()` (as well as `strncmp()` which I am currently using in
> lieu of `str_starts_with()`) forces you to provides the
On Mon, Jul 8, 2019 at 3:38 PM Nikita Popov wrote:
> On Mon, Jul 8, 2019 at 1:55 PM Zeev Suraski wrote:
>
>>
>>
>> On Mon, Jul 8, 2019 at 1:28 PM Nikita Popov wrote:
>>
>>> I have now made the following changes to the RFC:
>>>
>>>
On Mon, Jul 8, 2019 at 1:28 PM Nikita Popov wrote:
> I have now made the following changes to the RFC:
>
> * Removed enable_dl deprecation. The fact that dl() is currently available
> by default on CGI, which is a server SAPI, makes this more dicey and needs
> more careful consideration. As this
On Mon, Jun 17, 2019 at 1:55 PM Nikita Popov wrote:
> On Fri, May 24, 2019 at 6:53 PM Peter Kokot wrote:
>
> > Hello,
> >
> > On Sat, 11 May 2019 at 20:56, Peter Kokot wrote:
> > >
> > > Not trying to rush anyone to something they have no energy working on
> > > anymore here but what's the plan
On Sat, Jun 22, 2019 at 10:23 AM Kalle Sommer Nielsen wrote:
> Hi
> Den lør. 22. jun. 2019 kl. 02.04 skrev Stanislav Malyshev <
> smalys...@gmail.com>:
> > My first question for many of those is - why? I.e. it deprecates a bunch
> > of niche functions. Most people do not use these functions, so t
On Fri, May 3, 2019 at 1:21 AM G. P. B. wrote:
> Evening internals,
>
> I am not going to go into the details of every email which got sent in the
> past two days as I am busy with Exam revision.
>
I was also kind of busy, but more importantly I wanted to wait a bit before
I reply - as my previo
On Tue, May 7, 2019 at 1:25 PM Gert wrote:
> Hello,
>
> If the plan is to remove it in 8.0, then i'd say its beneficial to already
> deprecate it in 7.4. This will give users an earlier warning that these
> upgrades need to happen.
We should definitely deprecate it before removing it, if we dec
1 - 100 of 1400 matches
Mail list logo
