> On Oct 21, 2020, at 8:50 AM, Larry Garfield <la...@garfieldtech.com> wrote: > > On Tue, Oct 20, 2020, at 11:08 PM, Mike Schinkel wrote: >>> On Oct 20, 2020, at 2:19 PM, Larry Garfield <la...@garfieldtech.com> wrote: >>> >>> A while back, Nikita mentioned that it should now be easy to offer an >>> abbreviated syntax for functions that are just a single expression. I >>> decided to take a crack at it and it turns out he was right. I thus offer >>> this RFC: >>> >>> https://wiki.php.net/rfc/short-functions >>> >>> Hopefully I made a decent enough case for it. It's entirely a convenience >>> factor, but I think for many OOP cases (getter methods and factored out >>> operations) and functional cases (where functions should generally be a >>> single expression conceptually) it does make the code nicer, more compact, >>> and more readable. >> >> Simple and elegant. I like it. >> >> I have two comments, but not about the feature. >> >> One comment is about the RFC itself, and the other is about a use-case >> used to justify the feature that could warrant its own bespoke feature. >> >> >> 1. The section on "Conditional methods" is really just an argument >> about the benefits of encapsulating complex logic into well-named >> functions as you could achieve exactly the same benefit with the >> existing function syntax. It does not appear to me that it provides >> any specific justification for the feature in the RFC. Should it really >> be part of the RFC? > > In pre-RFC discussion, one of the pushbacks I got was "pfft, how common are > single-line methods anyway?" That example is mainly to demonstrate "quite > common, actually, in fact common refactoring patterns tend to produce them a > lot." It's not the refactoring itself that benefits, per se, as it is the > refactoring technique produces functions that would benefit from it.
Thank you for clarifying. I understand now why you included that section. I think the problem I had understanding the section's purpose was the construction of the first sentence where "common refactoring technique" was its subject. May I propose you consider a different construction that focuses on the frequency with which single-expression functions are needed? Here is but one such potential alternate: ----- "One might ask how commonly we need single-expression functions? Consider the "if," "switch" and "while" statements. When their expressions are complex, we can add clarity by encapsulating into a single-expression function:" ----- Also it might be good to rename the section "Conditional methods" to something like "Use-case frequency" to focus on the reason for inclusion, or if the purpose of the heading needs to be about how it would be used in the language then maybe "Control Flow Statement Expressions" would be more appropriate? Anyway, just offering these suggestion in hopes that ensuring your RFC is as clear as it can be will make it more likely to pass. -Mike > >> 2. In the section "Decorating functions in live code" where you state >> "Often times, methods exist that are just delegating to some other >> method, either in the same object or a composed object." I think we >> could see great benefit from explicitly building delegation into >> classes much like how Go provides type embedding[1]. For PHP, extending >> the syntax for traits could be used to support delegation of one class >> to another embedded class. Can you see this as a potential feature? >> >> -Mike > > I'd be in favor of some kind of automated "delegate this interface's methods > to this object property" syntax, although that is unrelated to the RFC at > hand. > > --Larry Garfield
