Hi
Den lør. 22. jun. 2019 kl. 02.04 skrev Stanislav Malyshev :
> 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 they
> probably don't care. Those they do use them would find their code broken
> or produce new
Just a note on process.
It is not necessary to hold multiple RFC's:
> For procedural reasons, multiple RFCs may be combined into one, in which
case there may be multiple primary votes.
> Combining multiple RFCs into one does not allow turning a primary vote
into a secondary vote.
In general, som
> Le 22 juin 2019 à 09:22, Kalle Sommer Nielsen a écrit :
>
> Hi
> Den lør. 22. jun. 2019 kl. 02.04 skrev Stanislav Malyshev
> :
>> 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 they
>> probably don't
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 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
Hi,
With regards to the array_key_exists() deprecation, the RFC currently
says nothing about things like ArrayAccess and object properties that
contain arrays. I'm sure that these are exceptions that aren't meant
to be deprecated, but can you please specify that explicitly? We all
know how little
On Sat, Jun 22, 2019 at 2:24 PM Andrey Andreev wrote:
> Hi,
>
> With regards to the array_key_exists() deprecation, the RFC currently
> says nothing about things like ArrayAccess and object properties that
> contain arrays. I'm sure that these are exceptions that aren't meant
> to be deprecated,
On 20/06/2019 23:30, Mark Randall wrote:
There does at least seem to be the starting point in that mb_string is
already widely used, and my suggestion that it "work as expected" is
more that it would work as the equivalent mb_string / iconv function
would.
I think this is a rather short-sigh
On Thu, Jun 20, 2019 at 12:32 AM wrote:
> I sent this earlier this week without [RFC] in the subject line...since
> some people might have filters to check the subject line I wanted to
> send this again with the proper substring in the subject line–to make it
> clear I intend to take this to a vo
> Also, it's unclear to me why get_called_class() should be deprecated.
> While the rest of the listed deprecations have either motivation
> written for them or are self-evidently legacy functionalities that
> nobody should be using today, this one seems to be just a case of
> "let's not have m
On Sat, Jun 22, 2019 at 6:11 PM Pieter Hordijk
wrote:
>
>
> > Also, it's unclear to me why get_called_class() should be deprecated.
> > While the rest of the listed deprecations have either motivation
> > written for them or are self-evidently legacy functionalities that
> > nobody should be usin
Hi!
> While I understand where you are coming from on this, I do think that
> functionality that is better supported by dedicated extensions to do
> the job instead of providing some functions in the standard library
> that converts from a few specific encodings to another:
It may be supported by
Hi!
> In general, something is considered a primary vote if it could be
> conducted independently of other primary votes in the same RFC - ie, it
> is not an implementation detail.
>
> So, what we have here is multiple primary votes ...
I am not talking bureaucracy here, I'm talking about discus
> On Jun 22, 2019, at 10:32, Nikita Popov wrote:
>
>> On Thu, Jun 20, 2019 at 12:32 AM wrote:
>>
>> I sent this earlier this week without [RFC] in the subject line...since
>> some people might have filters to check the subject line I wanted to
>> send this again with the proper substring in t
Hi!
enable_dl - I am not clear what is proposed - to remove dl()
functionality in PHP 8 completely, even in CLI? Or to keep it in CLI
always on and remove the directive?
My opinion: drop the directive, let the SAPI decide if dl() is possible,
with CLI keeping it. Not sure about embed though. But I
On Sat, Jun 22, 2019 at 6:32 PM Nikita Popov wrote:
>
> The normal str_starts_with() function is perfectly safe to use on UTF-8
> strings,
Only if you assume strings to be normalized to the same form. Checking if NFC
string starts with NFD substring by checking them bit by bit is going
to yield
On Sat, Jun 22, 2019 at 10:27 PM Bruce Weirdan wrote:
> On Sat, Jun 22, 2019 at 6:32 PM Nikita Popov wrote:
> >
> > The normal str_starts_with() function is perfectly safe to use on UTF-8
> strings,
>
> Only if you assume strings to be normalized to the same form. Checking if
> NFC
> string sta
On 22.06.2019 at 21:31, Stanislav Malyshev wrote:
>> While I understand where you are coming from on this, I do think that
>> functionality that is better supported by dedicated extensions to do
>> the job instead of providing some functions in the standard library
>> that converts from a few spec
Hi,
On Sat, Jun 22, 2019 at 3:59 PM Nikita Popov wrote:
>
> On Sat, Jun 22, 2019 at 2:24 PM Andrey Andreev wrote:
>>
>> Hi,
>>
>> With regards to the array_key_exists() deprecation, the RFC currently
>> says nothing about things like ArrayAccess and object properties that
>> contain arrays. I'm
19 matches
Mail list logo
