> On Mar 24, 2021, at 11:22 PM, Levi Morrison via internals <internals@lists.php.net>
> wrote:
>
> On Wed, Mar 24, 2021 at 8:02 PM Mike Schinkel <mike@newclarity.net> wrote:
>>
>>> On Mar 24, 2021, at 8:39 PM, Larry Garfield <larry@garfieldtech.com> 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