[RFC] Short functions, take 2 View as Markdown

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.

PSR-12 may be unnecessarily verbose (I dislike PSR-12 myself, and have made no secret of that), but it is far and away the most widely used coding standard in PHP land so we cannot ignore its influence.

--
Larry Garfield
larry@garfieldtech.com

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