Re: [PHP-DEV] RFC: Support for multi-line arrow functions

[Brent Roose]

Hi internals

The reason multi-line short closures are so valued by userland devs is because 
they are shorter to write and prettier to read. While some of us might not 
agree on the definition of "prettier to read", it was one of the key arguments 
for adding short closures in the first place:

> Anonymous functions in PHP can be quite verbose, even when they only perform 
> a simple operation. Partly this is due to a large amount of syntactic 
> boilerplate, and partly due to the need to manually import used variables. 
> This makes code using simple closures hard to read and understand. This RFC 
> proposes a more concise syntax for this pattern. [1]
> 

We can have the discussion again on whether we like short closures or not, but 
it turned out most of internals _and_ userland devs do — based on the vote 
count in the sigle line RFC and the reaction on Nuno's PR, as well as my 
experience from an OSS maintainer point of view.

Furthermore, the `use(*)` syntax misses the point of this proposal: it's not 
about being able to use all variables from the outer scope, it's about a clean 
syntax that's as short as possible — even when you personally disagree that it 
is. I've made the same argument before on this list: it's clear that the PHP 
community _wants_ these changes: named arguments, property promotions, short 
closures, … these are all features that aren't _necessary_, still they are 
great features of a modern-day language. 

I also want to quote from Larry Garfields book on thinking functionally in PHP 
[2], to demonstrate the signicant impact short closures already had today:

> “Combined with PHP’s overall clunky syntax for doing functional-esque code, I 
> generally didn’t go further than “pure functions are your friend,” either in 
> my own code or what I explained to others.
> 
> That is, until PHP 7.4.
> 
> PHP 7.4’s introduction of short lambdas is, as we’ll see in this book, a 
> game-changer. While it doesn’t make anything new possible, it makes a lot of 
> things suddenly practical. That makes all the difference, so I decided it was 
> time to buckle down and really dig into functional programming.”

Larry continues to write a whole book about functional programming in PHP, and 
short closures play a significant role. 

So I hope to see more input on Nuno's PR from a techinical point of view: 
what's missing, what's needed to get this to the RFC phase, … and not only 
discussions about what syntax we like or not, or whether there are other ways 
to solve the same problem. Please provide Nuno with actionable feedback. 

Kind regards
Brent

[1] https://wiki.php.net/rfc/arrow_functions_v2 
 
[2] https://leanpub.com/thinking-functionally-in-php 
 




> On 5 Oct 2020, at 12:39, Andreas Leathley  wrote:
> 
> On 05.10.20 12:15, Deleu wrote:
>> To me that seems like a great argument in favour of the proposal. If you'll
>> want all variables to be imported (which in this case makes completely
>> sense), then `fn() {}` or `fn() => {}` is much less verbose and inline with
>> the mentality to reach for short closures. We reach for short closures to
>> avoid `use()` and convey that the outer process is intertwined with the
>> inner process. `fn()` allows to strengthen the concept that there's no real
>> separation between running SQL stuff in a `callable` that wraps a database
>> transaction.
> 
> Not necessarily: the arrow functions were specifically implemented for
> very short anonymous functions with a return value. Making them more and
> more like the existing "function" syntax would lead to having two
> different ways of defining anonymous functions that mainly differentiate
> themselves by including the parent scope by default or not.
> 
> I like the "function () use (*)" suggestion because it is explicit and
> opt-in. A shorter syntax like "fn () {}" is less clear, and it could
> lead to many people always using fn just because it is faster to write
> (and less to think about), which then could lead to unintended side
> effects because variables are being copied from the parent scope each
> time. When you see a usage of "fn () {}" while reading code you would
> not know if the person used it because it was faster to write, or if the
> parent scope variables are really needed.
> 
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
> 

Re: [PHP-DEV] RFC: Support for multi-line arrow functions

[G. P. B.]

First, can you please bottom-post and not top-post.

On Tue, 6 Oct 2020 at 09:53, Brent Roose  wrote:

> Hi internals
>
> The reason multi-line short closures are so valued by userland devs is
> because they are shorter to write and prettier to read. While some of us
> might not agree on the definition of "prettier to read", it was one of the
> key arguments for adding short closures in the first place:
>
> > Anonymous functions in PHP can be quite verbose, even when they only
> perform a simple operation. Partly this is due to a large amount of
> syntactic boilerplate, and partly due to the need to manually import used
> variables. This makes code using simple closures hard to read and
> understand. This RFC proposes a more concise syntax for this pattern. [1]
> >
>
> We can have the discussion again on whether we like short closures or not,
> but it turned out most of internals _and_ userland devs do — based on the
> vote count in the sigle line RFC and the reaction on Nuno's PR, as well as
> my experience from an OSS maintainer point of view.
>

I didn't know we were meant to do code golfing with production code, might
have missed a memo somewhere.


> Furthermore, the `use(*)` syntax misses the point of this proposal: it's
> not about being able to use all variables from the outer scope,


If it's not about being able to use all variables (or even just one that is
irrelevant) from the outer scope, then what is the point?
Saving 6 characters by only writing fn() {} instead of function {}?


> it's about a clean syntax that's as short as possible — even when you
> personally disagree that it is. I've made the same argument before on this
> list: it's clear that the PHP community _wants_ these changes:


Wanting something isn't an argument. Looking at what part of the community
wants, we should be using @ for attributes.

named arguments, property promotions, short closures, … these are all
> features that aren't _necessary_, still they are great features of a
> modern-day language.
>

Obviously nothing is necessary, we could write assembler style with only
goto statements.

I also want to quote from Larry Garfields book on thinking functionally in
> PHP [2], to demonstrate the signicant impact short closures already had
> today:
>
> > “Combined with PHP’s overall clunky syntax for doing functional-esque
> code, I generally didn’t go further than “pure functions are your friend,”
> either in my own code or what I explained to others.
> >
> > That is, until PHP 7.4.
> >
> > PHP 7.4’s introduction of short lambdas is, as we’ll see in this book, a
> game-changer. While it doesn’t make anything new possible, it makes a lot
> of things suddenly practical. That makes all the difference, so I decided
> it was time to buckle down and really dig into functional programming.”
>
> Larry continues to write a whole book about functional programming in PHP,
> and short closures play a significant role.
>

Finally a resemblance of an actual argument.


> So I hope to see more input on Nuno's PR from a techinical point of view:
> what's missing, what's needed to get this to the RFC phase, … and not only
> discussions about what syntax we like or not, or whether there are other
> ways to solve the same problem. Please provide Nuno with actionable
> feedback.
>
> Kind regards
> Brent
>
> [1] https://wiki.php.net/rfc/arrow_functions_v2 <
> https://wiki.php.net/rfc/arrow_functions_v2>
> [2] https://leanpub.com/thinking-functionally-in-php <
> https://leanpub.com/thinking-functionally-in-php>
>

Jokes aside, the actionable feedback is to argue *why* auto capture of the
outer scope should be added to the
language as "it is very not PHP" a direct quote from Rasmus from his talk
"25 years of PHP" [1] and from the
same section one of the reasons why people don't mind the current single
line expression form is because it
doesn't look like a new scope.
As Rowan said in his analysis changing this specific behaviour of scope
being able to "leak" into another one
needs a lot of justification, the current short closure syntax doesn't even
use braces {} which are the de facto
signal in PHP that you are entering in a new scope.

Going back to the `use(*)` syntax: the reason why people propose this
extension (which is not mutually exclusive
with adding support for fn {} without outer scope capture, albeit strange)
is that it is more in PHP traditional design
philosophy. You can argue against this syntax and in favour of Nuno's, but
again it is NOT missing the point.

Moreover, Larry has also made a PR which extends short closures [2] in a
way I personally find way more appealing.

Regards

George P. Banyard

[1] https://youtu.be/Qa_xVjTiOUw?t=1895
[2] https://github.com/php/php-src/pull/6221

Re: [PHP-DEV] RFC: Support for multi-line arrow functions

[G. P. B.]

On Tue, 6 Oct 2020 at 11:28, G. P. B.  wrote:

> First, can you please bottom-post and not top-post.
>
> On Tue, 6 Oct 2020 at 09:53, Brent Roose  wrote:
>
>> Hi internals
>>
>> The reason multi-line short closures are so valued by userland devs is
>> because they are shorter to write and prettier to read. While some of us
>> might not agree on the definition of "prettier to read", it was one of the
>> key arguments for adding short closures in the first place:
>>
>> > Anonymous functions in PHP can be quite verbose, even when they only
>> perform a simple operation. Partly this is due to a large amount of
>> syntactic boilerplate, and partly due to the need to manually import used
>> variables. This makes code using simple closures hard to read and
>> understand. This RFC proposes a more concise syntax for this pattern. [1]
>> >
>>
>> We can have the discussion again on whether we like short closures or
>> not, but it turned out most of internals _and_ userland devs do — based on
>> the vote count in the sigle line RFC and the reaction on Nuno's PR, as well
>> as my experience from an OSS maintainer point of view.
>>
>
> I didn't know we were meant to do code golfing with production code, might
> have missed a memo somewhere.
>
>
>> Furthermore, the `use(*)` syntax misses the point of this proposal: it's
>> not about being able to use all variables from the outer scope,
>
>
> If it's not about being able to use all variables (or even just one that
> is irrelevant) from the outer scope, then what is the point?
> Saving 6 characters by only writing fn() {} instead of function {}?
>
>
>> it's about a clean syntax that's as short as possible — even when you
>> personally disagree that it is. I've made the same argument before on this
>> list: it's clear that the PHP community _wants_ these changes:
>
>
> Wanting something isn't an argument. Looking at what part of the community
> wants, we should be using @ for attributes.
>
> named arguments, property promotions, short closures, … these are all
>> features that aren't _necessary_, still they are great features of a
>> modern-day language.
>>
>
> Obviously nothing is necessary, we could write assembler style with only
> goto statements.
>
> I also want to quote from Larry Garfields book on thinking functionally in
>> PHP [2], to demonstrate the signicant impact short closures already had
>> today:
>>
>> > “Combined with PHP’s overall clunky syntax for doing functional-esque
>> code, I generally didn’t go further than “pure functions are your friend,”
>> either in my own code or what I explained to others.
>> >
>> > That is, until PHP 7.4.
>> >
>> > PHP 7.4’s introduction of short lambdas is, as we’ll see in this book,
>> a game-changer. While it doesn’t make anything new possible, it makes a lot
>> of things suddenly practical. That makes all the difference, so I decided
>> it was time to buckle down and really dig into functional programming.”
>>
>> Larry continues to write a whole book about functional programming in
>> PHP, and short closures play a significant role.
>>
>
> Finally a resemblance of an actual argument.
>
>
>> So I hope to see more input on Nuno's PR from a techinical point of view:
>> what's missing, what's needed to get this to the RFC phase, … and not only
>> discussions about what syntax we like or not, or whether there are other
>> ways to solve the same problem. Please provide Nuno with actionable
>> feedback.
>>
>> Kind regards
>> Brent
>>
>> [1] https://wiki.php.net/rfc/arrow_functions_v2 <
>> https://wiki.php.net/rfc/arrow_functions_v2>
>> [2] https://leanpub.com/thinking-functionally-in-php <
>> https://leanpub.com/thinking-functionally-in-php>
>>
>
> Jokes aside, the actionable feedback is to argue *why* auto capture of the
> outer scope should be added to the
> language as "it is very not PHP" a direct quote from Rasmus from his talk
> "25 years of PHP" [1] and from the
> same section one of the reasons why people don't mind the current single
> line expression form is because it
> doesn't look like a new scope.
> As Rowan said in his analysis changing this specific behaviour of scope
> being able to "leak" into another one
> needs a lot of justification, the current short closure syntax doesn't
> even use braces {} which are the de facto
> signal in PHP that you are entering in a new scope.
>
> Going back to the `use(*)` syntax: the reason why people propose this
> extension (which is not mutually exclusive
> with adding support for fn {} without outer scope capture, albeit strange)
> is that it is more in PHP traditional design
> philosophy. You can argue against this syntax and in favour of Nuno's, but
> again it is NOT missing the point.
>
> Moreover, Larry has also made a PR which extends short closures [2] in a
> way I personally find way more appealing.
>
> Regards
>
> George P. Banyard
>
> [1] https://youtu.be/Qa_xVjTiOUw?t=1895
> [2] https://github.com/php/php-src/pull/6221
>

Ressending to the list as I seem to have mes

Re: [PHP-DEV] RFC: Support for multi-line arrow functions

[G. P. B.]

On Tue, 6 Oct 2020 at 12:20, Brent Roose  wrote:

> The point of short closures, regardless of single line or multi line, is
> addressed (and agreed upon by the RFC votes) in the first pararaph of the
> RFC [1]. I'm not sure if I can add anything useful rather than saying "it's
> nice to be able to write more consise code. It feels a little more smooth".
>

The thing is, the RFC voters have agreed on single-*expression*, there is a
high likelihood that if multi-line
(i.e. multiple statements/expression) support was included in this RFC it
would have failed.
Why do I think this? Look at the previous vote:
https://wiki.php.net/rfc/short_closures
So your conclusion about what the voters agreed is completely nonsensical
here.


> There's actually one more argument to be made: they would make the use of
> closures more consistent for those of who _prefer_ short closures. Now
> you're forced to mix up both the short and long syntax. As an example, I
> use Laravel's collections [2] which provide a functional API to interact
> with lists of data. You often chain these calls, and are able to use short
> closures like 80% of the time, but sometimes you're forced to use the
> longer syntax.
>
> So that's my two arguments for multi-line closures
>
> - Making code less verbose, which is the _same_ goal of single-line short
> closures, which was accepted by the vast majority of PHP
> - Consistency with already existing single-line short closures
>

Ignoring the first point, refer back to the previous paragraph.
What consistency is there if there is no implicit return in the block form?
Sure it is annoying that for a 2-liner, where you probably won't "forget"
about
the fact that you are importing the outer scope it is annoying that you
need to
go the longer route. But that's not a sufficient argument IMHO.


> My point is that PHP is evolving towards a modern language, and with that
> come syntax changes that not everyone likes or wants to use. @ for
> attributes isn't chosen because it simply isn't possible to support that
> syntax, not because of what the community _and_ internals want or don't
> want. I don't think of this as a counter argument to my original point: PHP
> has seen a significant increase in syntax sugar additions over the past few
> years. If no one wanted those, they woulnd't have been voted in. Would you
> like to address that argument? Why are promoted properties, single-line
> short closures, named argument, etc added besides that there's a "want" for
> them?
>

The core difference here is that it doesn't change a *fundamental* aspect
of the language
(or in the case of single-expression closure it changes 3 aspects making
them very
special), you might not like this aspect but it is still present.


Obviously nothing is necessary, we could write assembler style with only
goto statements.

That's exactly what I'm saying! It's ok to add syntax to make a developer's
> life easier. There are cases where that's a good enough argument.
>

And this is not one of them, at least for me, and I don't think I'm alone
here.


> Why was auto capture added to single line short closures last year? We've
> had this discussion before, and the majority of internals voted "yes" back
> then. So instead of only re-iterating the same discussion, why not provide
> Nuno with useful feedback as well?
>

And once *again* short-closure don't *just* have the auto-import of the
outer scope going for it.
The other main features of the short closure are not applicable to a block
syntax.
 - the fact that there is an implicit return
 - it is a single expression, *no* braces therefore it doesn't look like it
creates a new scope.

You ignoring these facets which are key benefits which only apply to the
short closure case, to imply
the extension to multi-line is a "no-brainer" is not making a case for it.

My opinion is already that the way PHP does closures is the Sane Way To Do
It TM,
you have a dependency on a variable therefore you need to specify it, is
IMHO a good thing.

Do other languages function just fine with the opposite behaviour, sure. At
the same time Java
has implicit nullable type arguments and people deal with it.


Best regards

George P. Banyard

[PHP-DEV] Stream filter may loose final block of data

[Christoph M. Becker]

Hi all,

as outlined in bug #77069[1], a stream filter may loose (aka. skip) the
final data block.  That bug report has some duplicates: #48725, #79984
and #77080.

Several weaks ago I made PR #6001[2] which would fix this issue, but I'm
not sure whether that change would violate the assumption that the
PSFS_FLAG_FLUSH_CLOSE flag will only ever be passed if no further data
is to be processed.

Could someone more proficient with the streams layer than I am please
clarify whether that is a valid assumption in the first place?

[1] 
[2] 

Thanks,
Christoph

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

[PHP-DEV] Re: Attributes and constructor property promotion

[Nikita Popov]

On Mon, Sep 28, 2020 at 12:36 PM Nikita Popov  wrote:

> Hi internals,
>
> When the constructor property promotion landed, the question of how it
> interacts with attributes on promoted properties did not get fully
> resolved. See https://wiki.php.net/rfc/constructor_promotion#attributes
> for what the issue is.
>
> The behavior that landed was to apply the attribute is applied to both the
> parameter and the property. However, this was with the understanding that
> we may have to adjust the behavior later, in particular depending on how
> the whole "attribute target validation" turns out. The way it is now, using
> a property-only attribute on a promoted parameter may result in spurious
> validation errors.
>
> I wanted to bring up this topic now to make sure it's not forgotten... I
> still don't really know what the best behavior here is.
>
> Regards,
> Nikita
>

I want to bump this topic, we should resolve this one way or another soon.
My two proposals are:

https://github.com/php/php-src/pull/6244: Suppress target validation errors
for promoted properties (for property/parameter targets, the rest gets
validated as usual).

https://github.com/php/php-src/pull/6285: Forbid use of attributes on
promoted properties altogether, punting on making a decision here.

Regards,
Nikita

Re: [PHP-DEV] Attributes and constructor property promotion

[Sara Golemon]

On Mon, Sep 28, 2020 at 5:36 AM Nikita Popov  wrote:

> When the constructor property promotion landed, the question of how it
> interacts with attributes on promoted properties did not get fully
> resolved. See https://wiki.php.net/rfc/constructor_promotion#attributes
> for
> what the issue is.
>
> The behavior that landed was to apply the attribute is applied to both the
> parameter and the property. However, this was with the understanding that
> we may have to adjust the behavior later, in particular depending on how
> the whole "attribute target validation" turns out. The way it is now, using
> a property-only attribute on a promoted parameter may result in spurious
> validation errors.
>
> I wanted to bring up this topic now to make sure it's not forgotten... I
> still don't really know what the best behavior here is.
>
>
My opinion on constructor property promotion (CPP) is that it's something
for small value object classes and should probably be regarded as
code-smell on larger classes. At the same time, annotations belong with
more complex objects and not so much with small "struct-like" classes.

Given that position, I think we should err towards strictness in how
attributes are applied to CPP declarations.  That is, we should require
them to be meaningfully applicable to both arguments and properties in
order to be used in a CPP context.  If that's a problem for the consumer,
then they should avoid use of CPP.

-Sara

Re: [PHP-DEV] Attributes and constructor property promotion

[Andreas Leathley]

On 06.10.20 17:15, Sara Golemon wrote:

My opinion on constructor property promotion (CPP) is that it's something
for small value object classes and should probably be regarded as
code-smell on larger classes. At the same time, annotations belong with
more complex objects and not so much with small "struct-like" classes.

Given that position, I think we should err towards strictness in how
attributes are applied to CPP declarations.  That is, we should require
them to be meaningfully applicable to both arguments and properties in
order to be used in a CPP context.  If that's a problem for the consumer,
then they should avoid use of CPP.

-Sara


The current usage of annotations is quite often with small struct-like
classes though - I mainly use annotations (and will use attributes) for
data that needs to be validated, or entity-like classes that contain
data. Those classes are small and simple and would benefit greatly from
CPP and attributes used in combination, so it would be a pity to make
that impossible.

From my understanding suppressing the validation errors in this
particular case would be a good solution, or are there any serious
downsides to that?

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

Re: [PHP-DEV] Attributes and constructor property promotion

[Rowan Tommins]

On Tue, 6 Oct 2020 at 17:20, Andreas Leathley  wrote:

> From my understanding suppressing the validation errors in this
> particular case would be a good solution, or are there any serious
> downsides to that?
>


The downside presumably is that a library author could implement an
attribute with a property-only restriction, and therefore write code
handling parameter attributes with the assumption that that attribute won't
be present. If a consumer of the library makes use of constructor property
promotion, that assumption can be violated. I can't quite picture what that
code would look like, though, since it's always necessary to filter the
list of attributes to exclude those from other libraries.

Regards,
-- 
Rowan Tommins
[IMSoP]

Re: [PHP-DEV] Attributes and constructor property promotion

[Benjamin Eberlei]

On Tue, Oct 6, 2020 at 6:21 PM Andreas Leathley  wrote:

> On 06.10.20 17:15, Sara Golemon wrote:
> > My opinion on constructor property promotion (CPP) is that it's something
> > for small value object classes and should probably be regarded as
> > code-smell on larger classes. At the same time, annotations belong with
> > more complex objects and not so much with small "struct-like" classes.
> >
> > Given that position, I think we should err towards strictness in how
> > attributes are applied to CPP declarations.  That is, we should require
> > them to be meaningfully applicable to both arguments and properties in
> > order to be used in a CPP context.  If that's a problem for the consumer,
> > then they should avoid use of CPP.
> >
> > -Sara
>
> The current usage of annotations is quite often with small struct-like
> classes though - I mainly use annotations (and will use attributes) for
> data that needs to be validated, or entity-like classes that contain
> data. Those classes are small and simple and would benefit greatly from
> CPP and attributes used in combination, so it would be a pity to make
> that impossible.
>
>  From my understanding suppressing the validation errors in this
> particular case would be a good solution, or are there any serious
> downsides to that?
>

This is my argument as well. Attributes + CPP are a powerful combination.

Attributes are an important use-csae for data transfer objects, to
configure validation or serialization for example:

class ChangeFirstNameRequest
{
public function __construct(
#[Validate\IsPositive]
public int $id;
#[Validate\NotBlank]
#[Json("first_name")]
 public string $firstName;
) {}
}


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