On 2019-07-08 17:52, Ben Ramsey wrote:
On Jul 8, 2019, at 13:09, Björn Larsson
wrote:
Having this _ci postfix is a new way of indicating case
insensitivity.
I think that it might add to negative votes. Personally I think it's a
good idea to mimic existing ways, even if they are a bit
Hi internals,
I've opened voting on the strict operators directive:
https://wiki.php.net/rfc/strict_operators
As promised, a patch and tests have been prepared. This is available on
https://github.com/php/php-src/pull/4375
Regards,
Arnold
On 08.07.2019 at 15:05, Andrew Gromov wrote:
>> Please don't switch behaviours via flags: separate names and
>> implementations are much clearer and much simpler to follow.
>>
>> Yes, you will have multiple variations, but that's fine.
>
>
> It is depends of preferences.
>
> In my opinion, create
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:
>>>
>>> * Removed enable_dl deprecation. The fact that dl() is
On Sun, Jul 7, 2019 at 3:45 PM Theodore Brown
wrote:
> For those voting against adding these functions, can you clarify why?
>
Explaining my non-vote. I'm explicitly abstaining as I don't see the value
in these functions (I'd rather see a community driven library which does
the same thing in a
Hi,
On Mon, Jul 8, 2019 at 4:54 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
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
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
On Mon, July 8, 2019 at 9:10 AM Sara Golemon wrote:
> On Sun, Jul 7, 2019 at 3:45 PM Theodore Brown wrote:
>
> > For those voting against adding these functions, can you clarify why?
>
> Explaining my non-vote. I'm explicitly abstaining as I don't see the
> value in these functions (I'd
The deprecation RFC lists `apache_request_headers()`, because it is “an
Apache-specific name is also available in other SAPIs, even though it is also
available under the SAPI-independent name getallheaders()”.
Have you ever thought about making a more thorough and consistent change with
other
On Mon, Jul 8, 2019 at 3:41 PM Claude Pache wrote:
> The deprecation RFC lists `apache_request_headers()`, because it is “an
> Apache-specific name is also available in other SAPIs, even though it is
> also available under the SAPI-independent name getallheaders()”.
>
> Have you ever thought
> 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 substring and the length of
the substring, instead of just the
On Mon, Jul 8, 2019 at 4:01 PM Zeev Suraski wrote:
>
>
> 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:
Hi!
Please note that feature freeze for 7.4 is in exactly two weeks (July 22nd).
7.4.0beta1 will be cut in the morning of July 23rd, BST. By that time all code
related to RFCs must be merged, which means today is the last day to start
voting on RFCs.
cheers,
Derick (and Peter)
--
PHP
For those voting against adding these functions, can you clarify why?
Do you dislike how they are named, or do you not see the need for the
case insensitive versions, or is there an issue with the implementation?
I believe that star_with/end_with is useful, but not in this form.
The standard
On Fri, Jul 5, 2019 at 4:37 PM Nikita Popov wrote:
> On Sat, Jun 22, 2019 at 10:21 PM Stanislav Malyshev
> wrote:
>
>> 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
Den 2019-07-07 kl. 22:45, skrev Theodore Brown:
On Thu, July 4, 2019 at 9:13 PM Will wrote:
Hello all,
After 15 days of discussion I have opened up voting on the following
RFC (https://wiki.php.net/rfc/add_str_begin_and_end_functions).
Thank you for your work on this. I'm surprised that
Den 2019-07-05 kl. 03:48, skrev Theodore Brown:
On Thu, July 4, 2019 at 5:26 PM Björn Larsson wrote:
Den 2019-07-03 kl. 17:25, skrev Peter Bowyer:
Thanks for taking the time to push forward this RFC.
I found the earlier discussion at https://externals.io/message/104744,
which I hadn't
On Mon, Jul 8, 2019 at 6:56 PM Zeev Suraski wrote:
>
>
> 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
Hi all,
Minor issue really but a fair chunk of the emails I get from the
internals list end up in spam due to what looks like the DKIM signatures
being incorrect.
If a message is DKIM signed, the signed part usually contains subject
and body, this is then hashed and appended to the headers,
Hi internals,
I've opened voting on the deprecations for PHP 7.4 RFC:
https://wiki.php.net/rfc/deprecations_php_7_4
As usual, each deprecation has it's own vote and requires its own,
independent 2/3 majority to pass. Voting closes July 22nd.
Thanks everyone for their feedback.
Regards,
Nikita
Scott,
[using DKIM and (lax) DMARC myself, usually just lurking]
Am 08.07.19 um 21:29 schrieb sc...@exussum.co.uk:
> It looks like ezmlm is used, there is an option for headerremove which
> DKIM-Signature could be added to
>
> On Jul 8, 2019, at 13:09, Björn Larsson wrote:
>
> Having this _ci postfix is a new way of indicating case insensitivity.
> I think that it might add to negative votes. Personally I think it's a
> good idea to mimic existing ways, even if they are a bit awkward.
>
> How about using a flag or
On Mon, Jul 8, 2019, 12:15 Andrew Gromov wrote:
> > For those voting against adding these functions, can you clarify why?
> > Do you dislike how they are named, or do you not see the need for the
> > case insensitive versions, or is there an issue with the implementation?
>
>
> I believe that
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
Hello everybody,
I've just opened the vote on
https://wiki.php.net/rfc/pdo_escape_placeholders
voting will close in two weeks, on July 22nd.
Cheers
--
Matteo Beccati
Development & Consulting - http://www.beccati.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe,
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:
>>
>> * Removed enable_dl deprecation. The fact that dl() is currently
>> available
>> by default on CGI, which is a server SAPI,
On 7/8/2019 4:55 AM, Zeev Suraski wrote:
Why are we proactively making the lives of users more difficult for
literally no gain at all?
Zeev
Because that's what software developers tend to do when they are bored.
Instead of focusing on API stability, squashing bugs and other generally
Please don't switch behaviours via flags: separate names and
implementations are much clearer and much simpler to follow.
Yes, you will have multiple variations, but that's fine.
It is depends of preferences.
In my opinion, create new function for every possible situation is more worse
then
29 matches
Mail list logo
