On Tue, 24 May 2016 02:24:12 +0300, Dan Ackroyd <dan...@basereality.com>
wrote:
Hi Nikita,
On 23 May 2016 at 15:27, Nikita Nefedov <inefe...@gmail.com> wrote:
With this message I'd like to go to vote
with the Callable prototypes RFC targeted at 7.1:
https://wiki.php.net/rfc/callable-types
To explain my vote - I think we definitely need to be able to specify
the signatures of callables in PHP, and I would very probably support
either a 'typedef' RFC, or an expansion of current functional type
(i.e. invokables) to be easier to use with functions, but I just
couldn't possibly vote for an RFC that means people would sometimes
write code similar to this:
function foo(int $a, int $b,
callable(callable(callable(callable(int, int):int $zebranky, int):int
$pik, int):int $fot, int):int $zot): int {
return $zot($a, $b);
}
to use the feature of the RFC.
I realise that is an extreme case, but I think that splitting where a
type is defined (with a name) and the place where it is used to be
separate places, is one of the things that the design of PHP got
right. It makes it easier to read code, even if it makes the language
feel less 'powerful' than other languages.
cheers
Dan
Morning Dan,
I think we definitely would need type aliases. But I also hoped for
union types to get in, so that after these two we could have another RFC
that would do typedefs for callables and for unions.
Doing typedefs for callables only seems too narrow. People would
probably vote 'no' for that RFC because apart from creating new syntax for
callables it would also create a flavour of typedef that works in limited
scope only. And that seems completely fair, typedef is another feature.
And even with typedefs I see no reason not to support inline callable
prots.
Do you remember 'Arbitrary expressions' RFC? I look at it just like at
expressions, and I think there's a need for any possible type to be
expressed directly in a parameter typehint. Making code more readable
would be a responsibility of a user who would decide whether he needs
to use function signatures or not.
Regarding Joe's functional interfaces, I wish they were passing vote.
They can be a nice addition (and a pretty simple one) to the language.
I also think they are not related to this RFC, as their usage is completely
different... What I am aiming at with this (and possibly next) RFC is
to make function composition work better and functional interfaces don't
touch this subject at all. The fact that function needs to opt-in and
the fact that the signature of a function needs to be completely
same as in interface (so no variance) makes it useless in cases
where callable prototypes should be used instead.
I realise that is an extreme case, but I think that splitting where a
type is defined (with a name) and the place where it is used to be
separate places
I think so too but "callable(int): int" is not defining a type, it is
using it. On the other hand "callable" here is a type constructor.
If we would have generics of some form this would be similar to:
"Function<int, int>" where you don't define a type but you create it
passing "int, int" arguments to a type constructor (or a template,
or a generic class) which results in a type in the end. When you
get parametrized types there's a natural need for parameterizing
them in place...
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
