Re: [PHP-DEV] Re: [RFC][DISCUSSION] Match expression v2
On Fri, Jun 5, 2020 at 3:10 PM Ilija Tovilo wrote: > > 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 > weeks and put it to a vote then if there are no objections. I will > send another reminder one day before I do. > > Ilija > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > I really like this addition. đź‘Ť It's a great way to decrease code verbosity without getting in the way of anything else. Much better without the blocks too, since with blocks you might as well use functions or `switch`. I see you mentioned pattern matching, but I think this can be done quite well in userland. Have you thought about including ranges, greater/less than, or some form of `in_array()` matching? As for making the `(true)` optional, even though many are in favour of it. to me that seems like something that would happen when/if the `while (true)` becomes optional. There's a million examples of the latter on github, and I think it would be odd to make this optional while (no pun intended) the `while` one would not be. Thanks, Peter
Re: [PHP-DEV] [RFC] Shorter attribute syntax
Hi Rowan,
On Sun, June 7, 2020 at 5:32 PM Rowan Tommins wrote:
> On 07/06/2020 19:37, Theodore Brown wrote:
> > Yes, I agree that there's a judgment call to make. Out of curiosity,
> > given these shortcomings of the double-angle-bracket syntax, do you
> > think there are any objective reasons to prefer it over `@@` (other
> > than the theoretical BC break of code like `@@@really_suppress_me()`)?
>
> I'm not convinced there's any objective reasons to be found either way,
> but for the sake of "playing devil's advocate", here are a few that
> could be put forward:
>
> If grouped attributes are added, they're actually slightly less verbose
> than repeating a double-at prefix, once you have enough attributes in
> the set:
>
> Minimum spacing and punctuation requires n+3 chars vs 3n, so a saving
> even with 2 attributes:
> `<>class Bob{}`
> vs
> `@@Foo @@Bar class Bob{}`
>
> More realistic spacing is 2n+3 vs 3n, giving a saving only with 4 or more:
> `<>class Bob{}`
> vs
> `@@Foo @@Bar @@Baz @@Quux class Bob{}`
Neither of these are realistic examples, though. In practice, you're
not going to have an empty class definition on the same line as a
bunch of short attributes like this. Based on the Use Cases section
of the Attributes v2 RFC, [1] typically there would be three or fewer
attributes applied to a given entity.
The RFC only has one example with four attributes, which happens to be
a flattened version of the nested attributes use case discussed in the
Shorter Attribute Syntax RFC. But in this example, the attributes each
have one or more parameters, which makes them long enough that they
have to be on separate lines. And with sane formatting, the `<<>>`
syntax version still ends up being more verbose:
```php
// 170 characters for attributes (162 not counting leading whitespace)
<<
ManyToMany(Phonenumber::class),
JoinTable("users_phonenumbers"),
JoinColumn("user_id", "id"),
InverseJoinColumn("phonenumber_id", "id", JoinColumn::UNIQUE),
>>
private $phonenumbers;
// 160 characters for attributes
@@ManyToMany(Phonenumber::class)
@@JoinTable("users_phonenumbers")
@@JoinColumn("user_id", "id")
@@InverseJoinColumn("phonenumber_id", "id", JoinColumn::UNIQUE)
private $phonenumbers;
```
So the idea that the `<<>>` syntax with grouped attributes will be
less verbose than the `@@` syntax turns out not to be the case in
real-world use cases.
> Bracket-based syntaxes, particularly with grouping, are more clearly
> separated from the main code, particularly when used inline. For instance:
>
> `$f = @@Something @@AnotherThing function(@@Special @@ReallyInt int $var)
> {};`
> vs
> `$f = <> function(<> int $var)
> {};`
To me there doesn't seem to be a big difference in readability between
the function attributes in this example. And with syntax highlighting,
the function keyword itself provides a very clear separation.
For the parameter attributes, the `@@` syntax example is actually
more readable to my eye. I can't help seeing the `>>` token as a
shift operator at first glance in this context.
> Finally, typing up those examples, it occurs to me that `@@` is quite a
> "heavy" symbol - it has a large proportion of black (or whatever colour)
> pixels - and inevitably a rather "fussy" one. I find it draws the eye
> more than the angle-brackets do, which feels unfortunate.
I guess this is somewhat dependent on the font you're using. But in
general I don't think that the symbol being "heavy" is necessarily
a bad thing. It can help attributes stand out better from function
calls, generics, and other nearby syntax.
Best regards,
Theodore
[1]: https://wiki.php.net/rfc/attributes_v2#use_cases
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Session default settings (use_strict_mode)
> Le 7 juin 2020 à 22:15, AllenJB a écrit : > > Are there any other session (security) related settings that should be > tightened by default? (cookie_samesite?) Yes, of course: * session.cookie_httponly should be "1" by default. * session.cookie_samesite should be "Lax" by default. * Ideally, session.cookie_secure should be enabled by default on https; sadly, the setting does not allow to have different values for secure and insecure connections. —Claude
Re: [PHP-DEV] [RFC] Shorter attribute syntax
On 07/06/2020 19:37, Theodore Brown wrote:
If `<> )>>` means something like `new Foo( new Bar )`, then I
can imagine it being useful for `<> )>>` to mean
`new Foo( [new Bar, new Baz] )`. That would actually be more convenient than
the double-at version, where you'd have to write `@@Foo( [@@Bar, @@Baz] )`
or use a constructor with a `...$variadic` parameter.
In that example there are the same number of characters either way, so
it's not clear the nested `<<>>` approach would be more convenient.
And do you think it's a good idea to have an additional syntax for
creating arrays like that? It seems like it could get confusing.
True, it doesn't make a huge amount of difference.
My thinking was that passing a list of attributes as arguments to
another would be quite a common case, and would add value to the special
"nested attributes" syntax, which is otherwise just a weird spelling of
"new" to work around implementation problems (if indeed it does actually
work around them).
Ultimately, it all comes down to judgement calls - is the
double-angle-bracket syntax "too verbose", "too ugly" when nested, etc;
and does the double-at syntax make it "better enough".
Yes, I agree that there's a judgment call to make. Out of curiosity,
given these shortcomings of the double-angle-bracket syntax, do you
think there are any objective reasons to prefer it over `@@` (other
than the theoretical BC break of code like `@@@really_suppress_me()`)?
I'm not convinced there's any objective reasons to be found either way,
but for the sake of "playing devil's advocate", here are a few that
could be put forward:
If grouped attributes are added, they're actually slightly less verbose
than repeating a double-at prefix, once you have enough attributes in
the set:
Minimum spacing and punctuation requires n+3 chars vs 3n, so a saving
even with 2 attributes:
<>class Bob{}
vs
@@Foo @@Bar class Bob{}
More realistic spacing is 2n+3 vs 3n, giving a saving only with 4 or more:
<>class Bob{}
vs
@@Foo @@Bar @@Baz @@Quuxclass Bob{}
Bracket-based syntaxes, particularly with grouping, are more clearly
separated from the main code, particularly when used inline. For instance:
$f = @@Something @@AnotherThing function(@@Special @@ReallyInt int $var) {};
vs
$f = <> function(<> int
$var) {};
Finally, typing up those examples, it occurs to me that @@ is quite a
"heavy" symbol - it has a large proportion of black (or whatever colour)
pixels - and inevitably a rather "fussy" one. I find it draws the eye
more than the angle-brackets do, which feels unfortunate.
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Session default settings (use_strict_mode)
Hi all, While writing an answer to someone regarding session security, I noticed that session.use_strict_mode is disabled by default, despite it being "mandatory for session security" (according to the description in the manual - https://www.php.net/manual/en/session.configuration.php#ini.session.use-strict-mode ). I tried a search of the mailing list and found an RFC declined 4 years ago, albeit with very few votes: https://externals.io/message/94484 Should use_strict_mode be enabled by default? My best guess is the previous RFC was declined due to the issues with lost sessions enumerated in the above linked thread. Do these still exist (have their been changes since this RFC)? Could the feature be improved to mitigate or remove these? If the setting default is not changed, should the manual description of this setting be improved to describe why it's not enabled by default? Are there any other session (security) related settings that should be tightened by default? (cookie_samesite?) AllenJB -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Shorter attribute syntax
Hi Rowan, On Sat, June 6, 2020 at 7:06 AM Rowan Tommins wrote: > The `::` token in the parser is called `T_PAAMAYIM_NEKUDOTAYIM`, and > personally I find `T_SL` and `T_SR` just as cryptic and irrelevant. The most > common place I see those token names is when accidentally running code > with conflict markers like "", or when messing up heredoc > syntax; even if they weren't so abbreviated, my reaction would be "shift > what now?" I've used bit-shifts maybe twice in the last ten years, so > it's just not an immediate association to me. > > "Disingenuous" was probably too strong a word, but I do think it relates > to a fundamental difference in viewpoint: to some people, `<<` and `>>` > are first and foremost the shift-left and shift-right operators, and so > the immediate association on seeing them is so obvious it's not worth > mentioning; to others, they just look like a new kind of brackets. > > That association might actually be a good reason to avoid that syntax, > but if so it should be spelled out, rather than taken as a given. That makes sense. I updated the RFC now to avoid usage of "shift tokens" in most places and instead refer to them as `<<` and `>>` tokens. I also added a sentence spelling out why the association with shift operators may be confusing for some developers. Additionally, the RFC more clearly lays out the issues with nested attributes now. > > Also, grouped attributes would probably have to be special-cased to > > be disallowed in nested attributes, since they don't make sense there. > > I'm not entirely clear how they work in current implementations like > Doctrine's, but I think nested attributes would have to have completely > different rules anyway, because you don't access them directly through > reflection in the same way. > > If `<> )>>` means something like `new Foo( new Bar )`, then I > can imagine it being useful for `<> )>>` to mean > `new Foo( [new Bar, new Baz] )`. That would actually be more convenient than > the double-at version, where you'd have to write `@@Foo( [@@Bar, @@Baz] )` > or use a constructor with a `...$variadic` parameter. In that example there are the same number of characters either way, so it's not clear the nested `<<>>` approach would be more convenient. And do you think it's a good idea to have an additional syntax for creating arrays like that? It seems like it could get confusing. > Ultimately, it all comes down to judgement calls - is the > double-angle-bracket syntax "too verbose", "too ugly" when nested, etc; > and does the double-at syntax make it "better enough". Yes, I agree that there's a judgment call to make. Out of curiosity, given these shortcomings of the double-angle-bracket syntax, do you think there are any objective reasons to prefer it over `@@` (other than the theoretical BC break of code like `@@@really_suppress_me()`)? 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
On Wed, 3 Jun 2020 at 23:11, Gabriel Caruso
wrote:
> On Wed, 3 Jun 2020 at 12:32, Nikita Popov wrote:
>
>> On Sun, May 31, 2020 at 11:20 PM Gabriel Caruso <
>> carusogabrie...@gmail.com> wrote:
>>
>>> On Sun, 31 May 2020 at 15:57, Nikita Popov wrote:
>>>
On Fri, May 29, 2020 at 6:45 PM Gabriel Caruso <
carusogabrie...@gmail.com> 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.
>>>
>>
>> Yes, it is allowed. It makes little sense in this particular case, but
>> it's allowed.
>>
>
> Ok, so let's allow that as well. I'll cover that with tests.
>
>
>>
>> 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).
>>>
>>
>> Why would this be a BC break? To make sure we're on the same page, I'm
>> suggesting to do the same as we do for __toString(), where if you declare
>>
>> public function __toString() {}
>>
>> we automatically convert it into
>>
>> public function __toString(): string {}
>>
>> internally.
>>
>
>> We could do the same for all other magic methods, and I don't think it
>> would introduce a particularly severe BC break.
>>
>> We did this for __toString() to work with the Stringable interface, and
>> we don't have the same requirement for other magic methods, but I still
>> think it's worth considering this for consistency reasons.
>>
>
> Ok, let me see if I understood it: so if someone creates a
>
> public function __set($name, $value) {}
>
> we would automatically convert (as per this RFC) to
>
> public function(string $name, mixed $value): void {}
>
> internally, right? Isn't this a BC if someone is returning something
> inside that method?
>
> Or no, are you talking that we only convert that for Reflection purpose?
>
>>
>> Nikita
>>
>
To exemplify my question: is this change that you are suggesting for us to
add: https://3v4l.org/JKj9f vs. https://3v4l.org/JKj9f/rfc#git-php-master?
Re: [PHP-DEV] Refactoring run-tests.php
On Sun, 7 Jun 2020, Max Semenik wrote: > On Fri, Jun 5, 2020 at 8:04 PM Nikita Popov wrote: > > > Happy to accept run-tests refactorings in general (there is a lot of > > global state to eradicate!), but please keep it single-file. We > > definitely need it single-file for distribution purposes, and I > > don't particularly want to have a "run-tests build system" for what > > I perceive to be little benefit. > > Once I add tests, it will just not be a single-file project anymore. I don't think tests are the relevant issue here. Nikita is asking to keep it a single file project for the test runner. I agree with that position. > > I'm not sure why PHP developers in particular seem to be so hung up about > > this issue, but: There really is no need to split every class into a > > separate file. This is how we develop in non-PHP, non-Java languages > > (C/C++/Rust/...) all the time. > > > > Because PHP taught them to: can't have a serious project > without the autoloader You don't need an autoloader if it's all in the same file. ;-) cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Deprecations for PHP 8.0
Den søn. 7. jun. 2020 kl. 12.18 skrev Deleu : > > What if Nikita changes the RFC to target PHP 8.1 but proceed with voting > now? If voting passes, the RFC will be pending implementation and the > "news" will start to spread. Brandt will write about it in his blog, Reddit > will have a post about it, etc. and the community will start to spread the > information. > Maybe even include 3-way voting and let people decide which version to > target. > > I'm still on the fence whether I like or dislike depredations coming on > 8.1, but my guess is that by carring on with the RFC now the information > will be spread and people will know about it. The question is, why is it important to delay deprecations when they can safely be ignored, functionality will remain the same anyway so it is only a problem for those whose development environments enable E_DEPRECATED in error_reporting. If Symfony (or any other project for the matter) wants to to have no deprecation warnings but cannot make the date for PHP 8.0.0's release, then they shouldn't target PHP8 and we should not delay our process due to that. Either way the changes proposed by this RFC is relatively small and the potential candidate that could hold some projects back (which I hope not), is the accessing static members on traits part, but likely minimal. By the time 8.1.0 is on the horizon, the list of potential deprecations could have doubled. It is important to have php.net be the source of truth for everything, so the official word on deprecations should come in the form of the documentation at php.net and the warnings emitted from php-src. We should not rely on others posting about these deprecations before they happen, everything and nothing can change in between now and when it is eventually implemented. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Deprecations for PHP 8.0
What if Nikita changes the RFC to target PHP 8.1 but proceed with voting now? If voting passes, the RFC will be pending implementation and the "news" will start to spread. Brandt will write about it in his blog, Reddit will have a post about it, etc. and the community will start to spread the information. Maybe even include 3-way voting and let people decide which version to target. I'm still on the fence whether I like or dislike depredations coming on 8.1, but my guess is that by carring on with the RFC now the information will be spread and people will know about it. On Sun, Jun 7, 2020, 06:46 Kalle Sommer Nielsen wrote: > Den søn. 7. jun. 2020 kl. 05.58 skrev Theodore Brown < > theodor...@outlook.com>: > > So while I understand the desire to make upgrades as easy as possible, > > I'm not convinced it's a good idea to delay these deprecations for > > a later release. At the very least if deprecation is likely the PHP > > manual should say something about it. > > I agree with this and feel very strongly about it, we should not delay > deprecations since they can be disabled on a configuration level by > removing the E_DEPRECATED bits from error_reporting anyway. Allowing > our users to know at the earliest possible moment when something is > going to be deprecated allows userland to have a larger time for > upgrading as these warnings about certain behavior will change many > years from now, but old behavior is still in effect. > > -- > regards, > > Kalle Sommer Nielsen > ka...@php.net > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
