Function list declaration syntax?

php.internals

Mike Schinkel

4 years ago
Hi all, This email proposes a shorthand syntax for declaring a list of single-expression functions. A similar albeit more verbose attempt to provide short functions[1] failed late last year, but I was recently inspired by Sebastian Bergmann's Type library[2] that he referenced in a comment on another thread. Consider the `Type` class[3] in the `SebastianBergmann\Type` namespace. It contains 60 lines of function declaration to define 14 functions that all return `false`. Even though it really is a simple class it is rather hard to wrap one's head around quickly because of all the bloating boilerplate required. At least IMO. Consider instead if we had the following syntax? public function list: bool { isCallable() => false, isFalse() => false, isGenericObject() => false, isIntersection() => false, isIterable() => false, isMixed() => false, isNever() => false, isNull() => false, isObject() => false, isSimple() => false, isStatic() => false, isUnion() => false, isUnknown() => false, isVoid() => false, } The idea here is to group a 'list' of functions — in this case of the same type — and then use shortened single expression fn() syntax for each function. And with a monospace font in your editor of choice this code could be made even easier to grok by left-aligning the return values. I chose the keyword `list` because it is already a reserved word, but the word `case` could also be used for the same reason, if people prefer that. Further, instead of `function list` or `function case` we could have `fn list`, `fn case`, `fn() list` or `fn() case`, whichever feels best to the most people. This could also work for abstract functions noting that the typehint is applied to each function instead of the list declaration, e.g.: abstract public function list { isAssignable(self $other): bool; name(): string; allowsNull(): bool; } Those two changes shorten Type.php from 140 lines down to 90 lines, and IMO, make the class much easier to read. You can see it here[4]. One more example, this time his `NullType` class[5] using mixed type hints and going from a total of 38 lines down to 26 lines[6]: public function list { name(): string => 'null', asString(): string => 'null', allowsNull(): bool => true, isNull(): bool => true, } What do you think? Is this approach any more appealing than the last one proposed? -Mike [1] https://wiki.php.net/rfc/short-functions [2] https://github.com/sebastianbergmann/type [3] https://github.com/sebastianbergmann/type/blob/master/src/type/Type.php [4] https://gist.github.com/mikeschinkel/6f8c9cf6700a75e75e2725db1ed4da61 [5] https://github.com/sebastianbergmann/type/blob/master/src/type/NullType.php [6] https://gist.github.com/mikeschinkel/a93aabd61127b0c3ba28c5caf4ebe005

Dan Ackroyd

4 years ago
On Tue, 5 Oct 2021 at 18:47, Mike Schinkel <mike@newclarity.net> wrote:
> Consider the `Type` class[3] in the `SebastianBergmann\Type` namespace. It contains 60 lines of function declaration to define 14 functions that all return `false`.
PHP allows you to define functions on one line: function isCallable(): bool { return false; } function isFalse(): bool { return false; } function isGenericObject(): bool { return false; } If you don't like having functions take up lots of lines, it's easier to just not follow that PSR guide line on formatting, rather than modify the language. cheers Dan Ack

Mike Schinkel

4 years ago
> On Oct 5, 2021, at 3:18 PM, Dan Ackroyd <Danack@basereality.com> wrote: > > On Tue, 5 Oct 2021 at 18:47, Mike Schinkel <mike@newclarity.net> wrote: > >> Consider the `Type` class[3] in the `SebastianBergmann\Type` namespace. It contains 60 lines of function declaration to define 14 functions that all return `false`. > > PHP allows you to define functions on one line: > > function isCallable(): bool { return false; } > function isFalse(): bool { return false; } > function isGenericObject(): bool { return false; }
The benefit I was proposing was not just fewer lines, but also reduced visual complexity making it easier to read and comprehend code quickly. Your argument addresses the former benefit but not the latter.
> If you don't like having functions take up lots of lines, it's easier > to just not follow that PSR guide line on formatting,
It is not always easier for developers where whose organizations dictate code standards. Besides, your alternative is a bit reductio ad absurdum.
> rather than modify the language.
You state this without justification that it has been established that changing the language is a bad thing. If that were true, why does the RFC process even exist as in most cases RFCs are passed to change the language? -Mike

Rowan Collins

4 years ago
On 09/10/2021 10:41, Mike Schinkel wrote:
> Besides, your alternative is a bit reductio ad absurdum.
I'm not sure what you mean by this. Dan's example is the first three lines of yours, written as currently valid PHP, and seems a reasonable comparison of how much the new syntax would save. If anything, it's your choice of example that exaggerates things - it's not that frequent that you have such a long list of methods, all returning the same type, and all with a hard-coded return value.
>> rather than modify the language. > You state this without justification that it has been established that changing the language is a bad thing. If that were true, why does the RFC process even exist as in most cases RFCs are passed to change the language?
That's not what Dan meant at all; he said that changing (or simply ignoring) coding standards is easier than changing the language. There's also the very real possibility of having to do both: the new syntax is added, but the authors of your favoured coding standard decide to discourage its use, and you're back at square one. All that said, you're not the first to point out that PHP's method syntax is more verbose than many; so far though, nobody has managed to get enough consensus behind any alternative, as with Larry's RFC that you mentioned. Regards,
-- Rowan Tommins [IMSoP]