Re: [PHP-DEV] [RFC] Amendments to Attributes

[Theodore Brown]

On Wed, May 20, 2020 at 12:07 PM Benjamin Eberlei  wrote:

> 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 the Amendments RFC to Attributes:
>
> 1. Proposing to add a grouped syntax <

Hi Benjamin,

I find the grouped attribute proposal somewhat troubling. The RFC
contains the following example:

```php
<>
public function test()
{
}
```

The problem with this syntax is that adding a new attribute at the 
start or end of the list, or removing one of the attributes, will
require modifying multiple lines. For some time the language has been
moving away from this (see the various RFCs to allow trailing commas
in more places), so this feels like a step backwards.

If trailing commas are allowed in grouped attributes, you could
write it this way instead:

```php
<<
  Attr2("foo"),
  Attr2("bar"),
>>
public function test()
{
}
```

But to me this still feels rather clunky. It requires two extra lines, 
and when moving from two attributes to one attribute (or vice versa),
you'd still probably end up modifying multiple lines.

Another issue with the grouped syntax is that comma separated
attributes can be easy to confuse with comma separated attribute 
arguments. For example:

```php
<>
<>
function bar() {}
```

It can be hard to tell which line contains multiple attributes vs.
multiple attribute arguments.

Ultimately it seems like the grouped attribute proposal is attempting
to work around the poor usability of the current verbose syntax. Maybe
it would be better to instead propose a simpler syntax that avoids
these issues. I know that some internals members expressed interest
in an `@@` token, but this was never voted on.

Having a distinct token for attributes would entirely avoid the issues
of having to modify multiple lines when adding/removing attributes, as
well as confusion with shift operators and comma-separated attribute
arguments. E.g. the RFC example would look like this instead:

```php
@@Attr2("foo")
@@Attr2("bar")
public function test()
{
}
```

To me this would be a lot cleaner and fit in better with the rest of
the language.

Best regards,
Theodore

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Ensure correct signatures of magic methods

[Gabriel Caruso]

On Sun, 31 May 2020 at 15:57, Nikita Popov  wrote:

> On Fri, May 29, 2020 at 6:45 PM Gabriel Caruso 
> wrote:
>
>> Hello, internals!
>>
>> I have opened the voting for
>> https://wiki.php.net/rfc/magic-methods-signature.
>>
>> The voting period ends on 2020-06-19 at 18h (CEST).
>>
>
> The RFC is a bit unclear on what is actually being proposed. It says
>
> > This RFC proposes to add parameter and return types checks per the
> following details.
>
> and goes on to list (reasonable looking) magic method signatures, but does
> not say how exactly those types are going to be checked. Is this going to
> require exactly the same signature, or is this going to be in accordance
> with variance rules? For example, are all of the following signatures valid
> under this RFC? Only the first two? None of them?
>
> // Narrowed return type from ?array
> public function __debugInfo(): array {}
>
> // Narrowed return type from mixed
> public function __get(string $name): int {]
>
> // Widened argument type from string
> public function __get(string|array $name): mixed {}
>


They are going to be checked following the variance rules, not the
*exactly* same as the RFC. I'll mention this, thanks for point it out.

Assuming this, your examples:

1 and 2. Will be valid, following the rules introduced by the `mixed` RFC.

3. Is that allowed in PHP? If so, the RFC will compliance with that.


>
> Also, is omitting the return type still permitted, even though it would
> nominally violate variance?
>
> public function __debugInfo() {}
>

Yes, this hasn't changed. The RFC only affects *typed* methods.


>
> Finally, if omitting the return type is permitted, will an implicit return
> type be added, like we do for __toString()? Would the method automatically
> become
>
> public function __debugInfo(): ?array {}
>

An implicit return type won't be added for any of the magic methods. I
believe that's a huge BC, and I don't want to debate that for PHP 8 (maybe
PHP 9, yes).


>
> and report as such from reflection?
>

I need more clearance on this one: are you asking how magic methods are
reported via Reflection and if that will be changed?


>
> Nikita
>

[PHP-DEV] Re: [VOTE] Opcache optimization without any caching

[tyson andre]

Hi internals,

I've added an "If you voted no, why?" section to this RFC 
https://wiki.php.net/rfc/opcache.no_cache#if_you_voted_no_why

Having this feedback may be useful to others working on similar things such as 
moving optimizations into core, in the future.

If there's any other feedback, let me know.

Thanks,
- Tyson
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Ensure correct signatures of magic methods

[Nikita Popov]

On Fri, May 29, 2020 at 6:45 PM Gabriel Caruso 
wrote:

> Hello, internals!
>
> I have opened the voting for
> https://wiki.php.net/rfc/magic-methods-signature.
>
> The voting period ends on 2020-06-19 at 18h (CEST).
>

The RFC is a bit unclear on what is actually being proposed. It says

> This RFC proposes to add parameter and return types checks per the
following details.

and goes on to list (reasonable looking) magic method signatures, but does
not say how exactly those types are going to be checked. Is this going to
require exactly the same signature, or is this going to be in accordance
with variance rules? For example, are all of the following signatures valid
under this RFC? Only the first two? None of them?

// Narrowed return type from ?array
public function __debugInfo(): array {}

// Narrowed return type from mixed
public function __get(string $name): int {]

// Widened argument type from string
public function __get(string|array $name): mixed {}

Also, is omitting the return type still permitted, even though it would
nominally violate variance?

public function __debugInfo() {}

Finally, if omitting the return type is permitted, will an implicit return
type be added, like we do for __toString()? Would the method automatically
become

public function __debugInfo(): ?array {}

and report as such from reflection?

Nikita

Re: [PHP-DEV] RFC: Error backtraces

[Nikita Popov]

On Fri, May 29, 2020 at 8:24 PM Max Semenik  wrote:

> Hi, I'd like to present a new RFC for your consideration:
> https://wiki.php.net/rfc/error_backtraces
>
> In a nutshell, I'm proposing to give errors equal rights with exceptions
> and provide backtraces for them, too.
>

I'm concerned about the performance implications of this change. Backtrace
gathering is quite expensive and doing this for every diagnostic will have
a large performance impact if there are many of them. This is okay if your
code is intended to be diagnostics clean, but unfortunately this is not a
given. If you generate 10k deprecation warnings during a request, you're
definitely going to feel those backtraces.

It is already possible to get a backtrace for all non-fatal diagnostics
through a custom error handler, which allows you to control whether you
want to collect a backtrace for a particular error. As such, I would
recommend to limit this functionality to fatal errors only, where such a
possibility does not currently exist. Additionally fatal errors also
naturally limit the performance impact, because there can (approximately)
be only one fatal error per request.

Nikita

Re: [PHP-DEV] Intersection types

[Gabriel Caruso]

On Sun, 31 May 2020 at 04:39, Larry Garfield  wrote:

> On Sat, May 30, 2020, at 3:02 AM, Gert de Pagter wrote:
> > Hi Internals,
> >
> > With recent additions of the type system like union types [1], id like
> > to propose adding intersection types as well.
> >
> > Looking through past RFCs I found one from 2016 [2] which never left
> > the discussion phase and is currently marked as inactive.
> > Before continuing with an RFC I'd like to know if there are any
> > particular reasons why the original RFC never got into a voting phase,
> > so that this one may be more successful.
> >
> > P.S. I’d also like to get RFC karma so I could create a proposal.
> >
> > Thanks in advance!
> >
> >
> > [1] https://wiki.php.net/rfc/union_types_v2
> > 
> > [2] https://wiki.php.net/rfc/intersection_types
> > 
>
> To my recollection, the original RFC was met with a general "meh, sounds
> complicated, and why would you want to do that?" which is why it never went
> as far as a vote.  I don't know if there was an implementation.  Note that
> it was proposed seemingly in conjunction with union types v1, and a lot of
> the discussion really confused the two.
>
> 4 years later, Nikita tried union types a second time and they sailed
> through.  I couldn't say why, but I speculate that it was a combination of
> 4 years of the community maturing, different people being around, and just
> union types without intersection types being an easier thing to swallow.
>
> I'd say go for it.  I'd love to see intersection types, as it would be
> very helpful to certain use cases with FIG PSRs.  (Eg, "I want an object
> that is a Response and also has the Link extensions from PSR-13 on it" is
> currently impossible to specify.  Intersection types would solve that
> perfectly.)
>
> --Larry Garfield
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php


I second everything that Larry said.