> On Mar 24, 2021, at 11:22 PM, Levi Morrison via internals
> <[email protected]> wrote:
>
> On Wed, Mar 24, 2021 at 8:02 PM Mike Schinkel <[email protected]> wrote:
>>
>>> On Mar 24, 2021, at 8:39 PM, Larry Garfield <[email protected]> wrote:
>>>
>>> As requested, splitting off the short-functions RFC to its own thread.
>>>
>>> https://wiki.php.net/rfc/short-functions
>>>
>>> In response to the feedback that the savings in typing volume is small,
>>> that's true but also not the main point. The main point is to allow and
>>> encourage functions to be written an in "expression style", that is, as
>>> actual functions and not procedures. As the RFC notes, such use cases are
>>> increasing, and is likely to increase in PHP, and that's overall a good
>>> thing for the language. It fits well with a number of recent RFCs both
>>> passed and proposed, and makes writing functional-style code much more
>>> natural.
>>
>> I like it.
>>
>> I hope this passes, and would vote for it if I had a vote.
>>
>> -Mike
>>
>> P.S. I do find myself lamenting that while this FRC makes code more concise
>> it does not do anything to reduce the (IMO overly) verbose nature of method
>> declarations that require both a visibility modifier and the function
>> keyword. And while I know you just stated that conciseness in not a main
>> goal, it is still a benefit of this proposal.
>>
>> It would be much nicer if we could indicate in fewer characters what the
>> visibility modifier and the function keyword currently denote. Yes, that
>> could be addressed in another RFC, but it could also be addressed in this
>> one — assuming there was a will do to so — so now felt like a good a time as
>> any to bring it up.
>>
>> Assuming others besides just me would like to see function signatures be
>> made less verbose and would like to see some proposed alternatives, please
>> ask and I will happily follow up with some ideas.
>
> Drop "public", as it is unnecessary. I never understood why
> PSR-whatever decided to always require it, when not all projects
> agreed on that, and there are actual arguments to put it only when
> overriding visibility (you see it only when it matters).
I have always understood the reason for `public` was that specifying it
indicates that the developer was making an explicit statement about visibility.
Of course with many developer's propensity for copy-paste and code generation,
I am not sure that argument is as sound as it might first appear.
I can think of two (2) approaches to minimize verbosity and address visibility
here. Consider this code:
class Product {
private Product $parent;
private string $name;
private int $counter;
public function getName():string { return $this->name; }
protected function getParent():Product { return $this->parent; }
private function getCounter():int { return $this->counter; }
}
The first approach would be to make the use of the "function" keyword
*optional* because, unless I am wrong, it should be unambiguous from a parser
perspective:
class Product {
private Product $parent;
private string $name;
private int $counter;
public getName():string => $this->name;
protected getParent():Product => $this->parent;
private getCounter():int => $this->counter;
}
The second approach — which I would much prefer, but I doubt many others in the
PHP world will — is to use a "method" keyword and to draw inspiration from
GoLang regarding visibility where leading uppercase method names are public,
leading lowercase names are protected, and leading underscore names are
private.
class Product {
property Product $_parent;
property string $_name;
property int $_counter;
method GetName():string => $this->_name;
method getParent():Product => $this->_parent;
method _getCounter():int => $this->_counter;
}
We could also do the same thing with properties by introducing a "property"
keyword, but I digress as shown in the second approach, but I digress...
Anyway, both of these two approaches would be backward compatible I think —
except the syntax of the second approach would not allow for revising existing
classes to the new syntax without also updating their calling code — but IMO
either would be a nice addition to the short function RFC, or possibly an RFC
of its own assuming there were enough others who would like to see the same?
> Anyway, it's
> not that important, as I don't have to do what PSR-whatever decided.
> Instead of writing this:
>
> ```
> class A
> {
> public function method($arg1)
> {
> return expr($arg1);
> }
> }
> ```
>
> I can write this:
>
> ```
> class A {
> function method($arg1) { return expr($arg1); }
> }
> ```
Honestly, I always omit "public" whenever I have the choice, too.
But there is always a lot of "other-people's code" to read and understand, much
of which uses PSR-12.
If there were a better syntax for visibility — such as proposed above — then
maybe a revised PSR could be released to recognize the newer syntax?
> To be quite honest, I like putting statements on a single line as long
> as they fit in whatever column limit the project uses. My
> .clang-format has been doing this for my C code and I've grown quite
> fond of it; there is real value in seeing more actual code on a page
> at a time, and I don't feel like it's too cramped.
Yes, I'd like to see more code on the page too! But I would also like more
whitespace so that there will be less of the non-whitespace to have to mentally
process.
-Mike
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
