Hello, internals,
Inspired by the bug report #75958 (http://bugs.php.net/75958), I'd like to
change the return type of some SPL methods that are always returning `true`
and only `true`.
These "always `true`" returns make no sense, as you can't wrap it in an
`if`/`else` to catch something that
Hello, internals.
I'd like to discuss with you a minor change that I'd like to make to PHP
8.0: change the return type of `__debugInfo` from `?array` to `array`.
The full context on how Máté found out that `__debugInfo` actually
returns an `?array` (which btw is not even documented:
Hi Benas,
This looks good to me.
Can you do a research on top 1k-2k most used composer packages and verify
how small the BC break it is?
Also, a suggestion on how to fix the BC issue if it exists could be
mentioned I guess.
Thank you,
Aled
On Wed, Jun 17, 2020, 02:11 Benas IML wrote:
> Hey
Hey internals,
This is a completely refined, follow-up RFC to my original RFC. Based on the
feedback I have received, this PR implements full validation and implicitly
enforces `void` rules on constructors/destructors while also allowing to
declare an **optional** explicit `void` return type.
On 16.06.2020 at 21:30, Benas IML wrote:
> I put the original RFC on hold and created a new PR [0] for implicitly
> enforcing `void` rules on both constructors and destructors. Note, that
> this results in a BC break since it is no longer legal to return non-void
> value from
On Tue, Jun 16, 2020 at 1:34 PM Nikita Popov wrote:
> On Tue, Jun 16, 2020 at 10:28 PM Davey Shafik wrote:
>
>>
>>
>> On Tue, Jun 16, 2020 at 1:52 AM Nikita Popov
>> wrote:
>>
>>> Hi internals,
>>>
>>> Inspired by the recent discussion on reserved keyword reservation, I'd
>>> like
>>> to
On Tue, Jun 16, 2020 at 10:28 PM Davey Shafik wrote:
>
>
> On Tue, Jun 16, 2020 at 1:52 AM Nikita Popov wrote:
>
>> Hi internals,
>>
>> Inspired by the recent discussion on reserved keyword reservation, I'd
>> like
>> to propose the following RFC:
>>
>>
On Tue, Jun 16, 2020 at 1:52 AM Nikita Popov wrote:
> Hi internals,
>
> Inspired by the recent discussion on reserved keyword reservation, I'd like
> to propose the following RFC:
>
> https://wiki.php.net/rfc/namespaced_names_as_token
>
> This RFC makes two related changes: Treat namespaced
I might suggest that we at least confine any renaming to things that
are user-visible and not worry about the source code. Except they're
going to need aliases for all time, that's just a fact. Although I'm
all about addressing the injustices of the past and present, I think
it would be a lot
Hey internals,
I put the original RFC on hold and created a new PR [0] for implicitly
enforcing `void` rules on both constructors and destructors. Note, that
this results in a BC break since it is no longer legal to return non-void
value from constructors/destructors. In other words, it is now
Hi Theodore,
wt., 16 cze 2020 o 18:57 Theodore Brown napisał(a):
> On Wed, June 3, 2020 at 6:54 PM Theodore Brown wrote:
>
> > Hi internals,
> >
> > I discussed the syntax for attributes further with Benjamin, Martin,
> > and several other internals developers off-list, and with their
> >
Hi,
> > Hi internals,
> >
> > I discussed the syntax for attributes further with Benjamin, Martin,
> > and several other internals developers off-list, and with their
> > feedback completed an RFC proposing to use the shorter `@@` syntax
> > instead of `<<>>` for attributes in PHP 8.
> >
> >
On Wed, June 3, 2020 at 6:54 PM Theodore Brown wrote:
> Hi internals,
>
> I discussed the syntax for attributes further with Benjamin, Martin,
> and several other internals developers off-list, and with their
> feedback completed an RFC proposing to use the shorter `@@` syntax
> instead of
Hi Björn
>>> I'd like to announce the match expression v2 RFC:
>>> https://wiki.php.net/rfc/match_expression_v2
>
> I do like this RFC and have one comment. Would it be suitable
> to have : as a separator instead of =>?
`=>` is usually used in combination expressions (arrays, yield, arrow
> On Jun 16, 2020, at 3:50 AM, Nikita Popov wrote:
>
> On Tue, Jun 16, 2020 at 8:59 AM Mike Schinkel wrote:
> Hi internals,
>
> Given that there appears to be some appetite to reduce checks for
> inappropriate signatures[1] I am wondering if anyone has strong opinions —
> pro or con — on
Den 2020-06-06 kl. 00:09, skrev Ilija Tovilo:
Hi internals
I'd like to announce the match expression v2 RFC:
https://wiki.php.net/rfc/match_expression_v2
Small reminder: Two weeks have passed since I announced the match v2
RFC with little new discussion. I'll leave it open for another two
On Tue, 16 Jun 2020 at 13:59, Dan Ackroyd wrote:
> To be clear, I'm not sure if I am in favour or against the RFC. The
> real problem is that constructors just don't fit into how we think
> about normal functions is PHP, because of the magic that goes on
> around them and so both void and null
Nope, that isn't changing.
I simply wanted to point out that this RFC is proposing to allow to declare
constructor return type as `: void`, but not as `: mixed`.
The entire RFC is just a matter of cosmetic addition allowing to add `:
void` to constructors/destructors (for those that want to).
On 16.06.2020 at 16:19, Benas IML wrote:
> I meant something like this:
> ```
> class Test {
> public function __construct() {}
> }
>
> class Test2 extends Test {
> /* this is legal */
> public function __construct(): void {}
> }
>
> class Test3 extends Test {
> /*
> * this
Exactly :)
Personally, I have numerous times caught myself declaring constructors `:
void` too. I would love to have everything consistent and all methods to
have a return type.
Although, I do understand that not everybody agrees with me and that's why
this RFC isn't planning to ever force
Hey Dan,
Thanks for your reply.
> No return type is _treated as_ 'mixed|void' in some circumstances
Could you elaborate? No return type DOES mean `mixed|void`, could you give
any pointers as to where that is different?
> I'm actually not sure exactly what you're trying to say there
I meant
On Tue, Jun 16, 2020 at 9:55 AM Lester Caine wrote:
> On 16/06/2020 13:14, Michał Brzuchalski wrote:
> > I'd like to start a discussion period for my RFC which proposes to change
> > the use of "blacklist" in Opcache configuration with better
> > self-descriptive terminology.
>
> Since there
>From a PHP developer's POV - when writing a class or refactoring one. I
have to catch myself all the time trying to declare ": void" on the
constructor. It's mostly a habit from doing so with the other methods in
the class. I lean in favor of being able to declare a void return type on a
On 16/06/2020 13:14, Michał Brzuchalski wrote:
I'd like to start a discussion period for my RFC which proposes to change
the use of "blacklist" in Opcache configuration with better
self-descriptive terminology.
Since there will be a higher level change to all these terms - in all
likelihood -
I would agree that, in the current global climate, merely commenting on
this RFC could have a significant impact outside of PHP internals on the
individual(s) participating - muchless voting on it. As an example if a
voting member has a product or service they offer - there is the
possibility for
> Le 16 juin 2020 à 14:14, Michał Brzuchalski a
> écrit :
>
> Hi Internals,
>
> I'd like to start a discussion period for my RFC which proposes to change
> the use of "blacklist" in Opcache configuration with better
> self-descriptive terminology.
>
>
> The RFC is here
+1 for this, exclude_list better explains code intent than blacklist.
--
Cheers,
Daniel Rodrigues.
geek...@php.net
https://twitter.com/geekcom2
De: Michał Brzuchalski
Enviado: terça-feira, 16 de junho de 2020 09:14
Para: PHP Internals List
Assunto: [PHP-DEV]
G.P.B. wrote:
> Seems like a no brainer and a good addition. :)
For situations where stuff is simple, 'no brainers' are okay.
For situations where everything is horribly convoluted, 'no brainers'
are often bad.
Benas IML wrote:
> even though no return type means mixed|void
Not quite.
No return
Hi
Den tir. 16. jun. 2020 kl. 15.33 skrev Alain D D Williams :
>
> Below is the standard footer to all list emails.
>
> It refers to an address that starts http:// - please can this be changed to
> https:// - which is what you get redirected to.
Send an email to syst...@php.net, they should be
Hi
Den tir. 16. jun. 2020 kl. 15.15 skrev Michał Brzuchalski
:
>
> Hi Internals,
>
> I'd like to start a discussion period for my RFC which proposes to change
> the use of "blacklist" in Opcache configuration with better
> self-descriptive terminology.
I disagree with this statement, and I do
Below is the standard footer to all list emails.
It refers to an address that starts http:// - please can this be changed to
https:// - which is what you get redirected to.
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Regards
--
On 16/06/2020 13:14, Michał Brzuchalski wrote:
I'd like to start a discussion period for my RFC which proposes to change
the use of "blacklist" in Opcache configuration with better
self-descriptive terminology.
IMHO this RFC should not come to a vote, the current RFC process is
ill-equipped
On Tue, 16 Jun 2020 at 13:15, Michał Brzuchalski
wrote:
>
> Hi Internals,
>
> I'd like to start a discussion period for my RFC which proposes to change
> the use of "blacklist" in Opcache configuration with better
> self-descriptive terminology.
Hi Michał,
Thanks for posting the RFC.
In my
Hi Internals,
I'd like to start a discussion period for my RFC which proposes to change
the use of "blacklist" in Opcache configuration with better
self-descriptive terminology.
The RFC is here https://wiki.php.net/rfc/change-terminology-to-excludelist
Discussions should remain on the list.
Any
On Tue, 16 Jun 2020 11:32:01 +0100 / Peter Bowyer
said :
> Hi list,
>
> 4 months ago there was a discussion about the future of SQLite3 and
> PDO/SQLite extensions (https://externals.io/message/108256),
> highlighting the effort required to maintain two codebases.
Yes and I haven't had time to
On Tue, Jun 16, 2020 at 12:42 PM Dan Ackroyd wrote:
> On Tue, 16 Jun 2020 at 11:32, Peter Bowyer
> wrote:
> >
> > If it is, how can we change and improve the current situation?
> >
>
> Hi Peter,
>
> I think what I wrote earlier is still a good approach:
>
On Tue, 16 Jun 2020 at 11:32, Peter Bowyer wrote:
>
> If it is, how can we change and improve the current situation?
>
Hi Peter,
I think what I wrote earlier is still a good approach:
https://externals.io/message/100773#100813
> Taking it to a better solution is that the method
Hi list,
4 months ago there was a discussion about the future of SQLite3 and
PDO/SQLite extensions (https://externals.io/message/108256), highlighting
the effort required to maintain two codebases.
Recently I encountered https://bugs.php.net/bug.php?id=64810 and thence
Mike Schinkel wrote:
> My primary use-case where I would like to see checked relaxed is
> for static methods used as factory methods[2].
Mike,
It's not reasonable to expect people to read multiple links and try
and guess what you're trying to say.
If you can't express the exact problem you're
On Tue, Jun 16, 2020 at 10:19 AM Marco Pivetta wrote:
> On Tue, Jun 16, 2020 at 11:05 AM Nikita Popov
> wrote:
>
>> The original RFC could at least
>> make a consistency argument, but the final form, which converts an
>> existing
>> special case into an even more convoluted special case, can
On Tue, Jun 16, 2020 at 11:06:17AM +0200, Eliot Lear wrote:
> Hi the peanut gallery...
>
> I can't say that blacklist/whitelist -> something else is a meaningless
> change. The challenge we as technologists (nevermind our color) have is
> that we don't really have good guidance from
On Tue, Jun 16, 2020 at 10:09 AM Peter Bowyer
wrote:
>
> So if we want to do this, let's:
>
> 1. Ask the black community what they find offensive in PHP
> 2. Listen
> 3. Prioritise the responses and judge which are feasible to act on
> 4. Act
>
This points out the obvious, people are stuck in
Hey Máté,
On Tue, Jun 16, 2020, 11:31 AM Máté Kocsis wrote:
> Hi Benas,
> Overall, I'm very much in favour of disallowing returning a value from
constructors.
> However, I think the RFC should deal with the return value and the
signature validation
> in the same time, so that we can vote about
Hey Nikita,
On Tue, Jun 16, 2020 at 11:05 AM Nikita Popov wrote:
> On Mon, Jun 15, 2020 at 10:43 PM Pedro Magalhães wrote:
>
> > Hi internals,
> >
> > I have opened the vote on the "Remove inappropriate inheritance signature
> > checks on private methods" RFC. Which can be found here:
> >
> >
Am 16.06.2020 um 10:52 schrieb Nikita Popov:
https://wiki.php.net/rfc/namespaced_names_as_token
+1
The RFC comes with a small backwards compatibility break related to names
that include whitespace, but will hopefully reduce the backwards
compatibility impact of future reserved keyword
Hi the peanut gallery...
I can't say that blacklist/whitelist -> something else is a meaningless
change. The challenge we as technologists (nevermind our color) have is
that we don't really have good guidance from psychologists and
sociologists (I know, I tried chasing down those links last year
On Mon, Jun 15, 2020 at 10:43 PM Pedro Magalhães wrote:
> Hi internals,
>
> I have opened the vote on the "Remove inappropriate inheritance signature
> checks on private methods" RFC. Which can be found here:
>
> https://wiki.php.net/rfc/inheritance_private_methods
>
> The voting period will end
Hi internals,
Inspired by the recent discussion on reserved keyword reservation, I'd like
to propose the following RFC:
https://wiki.php.net/rfc/namespaced_names_as_token
This RFC makes two related changes: Treat namespaced names as a single
token, which enables use of reserved keywords inside
Hi Benas,
Overall, I'm very much in favour of disallowing returning a value from
constructors.
However, I think the RFC should deal with the return value and the
signature validation
in the same time, so that we can vote about both, since introducing the
latter check
is not just a bug fix, it's a
On Mon, 15 Jun 2020 at 20:07, Thomas Nunninger
wrote:
> Before discussing technical aspects about what changes would be required
> and what are the consequences, I'd like to point out some other aspect:
>
> I'm a white guy. I can't tell women how they should feel about male
> wordings,
wt., 16 cze 2020 o 09:50 Nikita Popov napisał(a):
> On Tue, Jun 16, 2020 at 8:59 AM Mike Schinkel wrote:
>
> > Hi internals,
> >
> > Given that there appears to be some appetite to reduce checks for
> > inappropriate signatures[1] I am wondering if anyone has strong opinions
> —
> > pro or con
On Tue, Jun 16, 2020 at 8:59 AM Mike Schinkel wrote:
> Hi internals,
>
> Given that there appears to be some appetite to reduce checks for
> inappropriate signatures[1] I am wondering if anyone has strong opinions —
> pro or con — on removing checks for static methods?
>
> My primary use-case
Hi Mike,
wt., 16 cze 2020 o 08:59 Mike Schinkel napisał(a):
> Hi internals,
>
> Given that there appears to be some appetite to reduce checks for
> inappropriate signatures[1] I am wondering if anyone has strong opinions —
> pro or con — on removing checks for static methods?
>
> My primary
Hi internals,
Given that there appears to be some appetite to reduce checks for inappropriate
signatures[1] I am wondering if anyone has strong opinions — pro or con — on
removing checks for static methods?
My primary use-case where I would like to see checked relaxed is for static
methods
54 matches
Mail list logo
