Hi Internals,
We have just opened the vote on the PHP namespace in core RFC. The voting
will be
open for two weeks, until 2020-06-05 06:00 UTC.
Link: https://wiki.php.net/rfc/php-namespace-in-core#vote
Cheers,
Michał Marcin Brzuchalski
On Fri, 22 May 2020 at 12:09, Nikita Popov wrote:
> While I'm happy with "Attribute" living in the global
> namespace, I don't really think we'd want to introduce "Jit" as a class in
> the global namespace. The name is simply to generic and does not indicate
> that this is part of the attribute
On Fri, May 22, 2020 at 12:54 AM Rowan Tommins
wrote:
> * PHP has a very simple HTTP client implementation, used by the "http:"
> and "https:" stream wrappers, and also by extensions which make HTTP
> requests, such as ext/soap
Sorry, I'm an internals noob, but why does PHP implement this at
Hi internals
I'd like to announce the match expression v2 RFC:
https://wiki.php.net/rfc/match_expression_v2
The goal of the new draft is to be as simple and uncontroversial as
possible. It differs from v1 in the following ways:
* Blocks were removed
* Secondary votes were removed
* optional
On Wed, May 20, 2020 at 7:08 PM Benjamin Eberlei
wrote:
> Hi everyone,
>
> the Attributes RFC was rather large already, so a few things were left open
> or discussions during the vote have made us rethink a things.
>
> https://wiki.php.net/rfc/attribute_amendments
>
> These points are handled by
[2nd try, this time with proper etiquette]
Hi Rowan and Larry and others,
On 21.05.20 23:53, Rowan Tommins wrote:
>
> I would like to propose that the client advertises HTTP/1.1 in its
> requests by default in PHP 8.0. Users can opt out of this behaviour
> in a fully backwards- and
On Thu, May 21, 2020 at 11:54 PM Rowan Tommins
wrote:
> Hi all,
>
> A few years ago, I posted a message suggesting that PHP improve support
> for HTTP/1.1 in its stream wrapper functions:
> https://externals.io/message/96192
>
> A quick summary of the current situation:
>
> * HTTP/1.1 was
Agreed.
I don't think we should pollute any other than the `PHP\` namespace. If
that RFC doesn't pass though, we should keep the `Attribute` class in the
global namespace.
Global namespace is already reserved for PHP and so, BC breaks aren't that
severe whereas `Attributes\` namespace isn't
On Fri, May 22, 2020, at 6:08 AM, Ilija Tovilo wrote:
> Hi internals
>
> I'd like to announce the match expression v2 RFC:
> https://wiki.php.net/rfc/match_expression_v2
>
> The goal of the new draft is to be as simple and uncontroversial as
> possible. It differs from v1 in the following ways:
Hi Larry
> My one question is why you're not including the implicit "match (true)"
> in this version, when the secondary vote on the previous RFC was
> 80% in favor of it.
I received quite a bit of feedback that the RFC was too complex. I
tried to make the RFC simpler by removing all
On Fri, May 22, 2020 at 1:08 PM Nikita Popov wrote:
> On Wed, May 20, 2020 at 7:08 PM Benjamin Eberlei
> wrote:
>
>> Hi everyone,
>>
>> the Attributes RFC was rather large already, so a few things were left
>> open
>> or discussions during the vote have made us rethink a things.
>>
>>
Hi internals,
I want to put up for discussion an RFC (
https://wiki.php.net/rfc/inheritance_private_methods) that proposes to
remove some inappropriate signature checks that are still done on private
methods. Namely, those checks are:
- When a method has the same name as a parent's final private
On Fri, May 22, 2020 at 5:29 PM Benjamin Eberlei
wrote:
>
>
> On Fri, May 22, 2020 at 1:08 PM Nikita Popov wrote:
>
>> On Wed, May 20, 2020 at 7:08 PM Benjamin Eberlei
>> wrote:
>>
>>> Hi everyone,
>>>
>>> the Attributes RFC was rather large already, so a few things were left
>>> open
>>> or
On Fri, May 22, 2020 at 2:19 PM Benas IML wrote:
> Agreed.
>
> I don't think we should pollute any other than the `PHP\` namespace. If
> that RFC doesn't pass though, we should keep the `Attribute` class in the
> global namespace.
>
> Global namespace is already reserved for PHP and so, BC
Hey Ilija,
On Fri, May 22, 2020 at 1:08 PM Ilija Tovilo wrote:
> Hi internals
>
> I'd like to announce the match expression v2 RFC:
> https://wiki.php.net/rfc/match_expression_v2
> [...]
> Given that many people have said without blocks they'd vote yes I'd
> say this is the case here. Let me
On Fri, May 22, 2020 at 5:28 PM Nikita Popov wrote:
>
> I don't particularly care what namespace the attribute classes are under,
> just that they should have a common namespace, because there's going to be
> many of them, presumably. If it was just a matter of the Attribute class,
> I'd
> Am 22.05.2020 um 13:08 schrieb Nikita Popov :
>
> On Wed, May 20, 2020 at 7:08 PM Benjamin Eberlei
> wrote:
>
>> 2. Rename PhpAttribute to Attribute in global namespace (independent of the
>> namespace RFC)
>
> As was mentioned in one of the previous discussions, we expect that PHP is
>
Hey Pedro,
On Fri, May 22, 2020 at 5:43 PM Pedro Magalhães wrote:
> Hi internals,
>
> I want to put up for discussion an RFC (
> https://wiki.php.net/rfc/inheritance_private_methods) that proposes to
> remove some inappropriate signature checks that are still done on private
> methods. Namely,
On 22/05/2020 17:08, Katie Volz wrote:
I want to start a discussion on an RFC to add a declare() statement to
convert all errors triggered within a file to exceptions.
Hi Katie,
Personally, I'm not a fan of promoting messages to exceptions in this
way, because APIs designed to throw
Hello internals,
I want to start a discussion on an RFC to add a declare() statement to
convert all errors triggered within a file to exceptions.
Currently, the only way to handle notices/warnings in an exception-like
manner is via set_error_handler, (for example, example #1 on
On Fri, 22 May 2020 at 18:09, Katie Volz wrote:
> Hello internals,
>
> I want to start a discussion on an RFC to add a declare() statement to
> convert all errors triggered within a file to exceptions.
>
> Currently, the only way to handle notices/warnings in an exception-like
> manner is via
On 22/05/2020 07:14, Michał Brzuchalski wrote:
Hi Internals,
We have just opened the vote on the PHP namespace in core RFC. The voting
will be
open for two weeks, until 2020-06-05 06:00 UTC.
Link: https://wiki.php.net/rfc/php-namespace-in-core#vote
Cheers,
Michał Marcin Brzuchalski
I hope
On 22/05/2020 18:30, Mark Randall wrote:
Should this vote fail, \PHP effectively changes from a reserved
namespace, to a dead namespace.
I don't see how you get from the text of this RFC to that conclusion.
There are a number of reasons why people who vote against this RFC might
vote for an
Hey Bruce,
On Fri, May 22, 2020, 22:07 Bruce Weirdan wrote:
>
> On Fri, May 22, 2020 at 7:26 PM Marco Pivetta wrote:
>
>> Overall, this RFC breaks some design capabilities that are within the
>> language, specifically around `__`-prefixed methods in the language.
>
>
> Wouldn't your use cases
On 22/05/2020 19:32, Rowan Tommins wrote:
* They might even prefer your RFC, which is still marked "Under
Discussion": https://wiki.php.net/rfc/php_namespace_policy
Even though the two RFCs were seperate and created without each others
knowledge, I don't know how people would feel about
On Fri, May 22, 2020 at 7:26 PM Marco Pivetta wrote:
> Overall, this RFC breaks some design capabilities that are within the
> language, specifically around `__`-prefixed methods in the language.
Wouldn't your use cases be covered by `protected final` though, as proposed
by Pedro?
--
Best
On Fri, May 22, 2020, at 10:42 AM, Ilija Tovilo wrote:
> Hi Larry
>
> > My one question is why you're not including the implicit "match (true)"
> > in this version, when the secondary vote on the previous RFC was
> > 80% in favor of it.
>
> I received quite a bit of feedback that the RFC was too
27 matches
Mail list logo
