Re: [PHP-DEV] [RFC]

This is only part of a thread. view whole thread
  108508
February 12, 2020 14:08 Danack@basereality.com (Dan Ackroyd)
On Tue, 11 Feb 2020 at 13:19, Nikita Popov ppv@gmail.com> wrote:

btw it's probably worth mentioning the other reason I didn't pursue
https://wiki.php.net/rfc/consistent_callables.

By itself, the callable type isn't much use. It only allows you to
specify that a type can be called, but it doesn't allow you to specify
what parameters the callable should take, or what the return type
should be.

Just making the callable type be consistent would be a lot of work,
and possibly cause a lot of BC breaks and still not do the useful
thing.

Instead what would be far more useful would be allow people to define
the callable signature, and use that as a type.

callable some_callback(int $x, string $y) : int;

function bar(some_callback $fn) {  }

$fn_correct = function (int $x, string $y) : int {}
$fn_wrong = function (int $x, string $y) : int {}

Calling bar with $fn_correct should work.
Calling bar with $fn_wrong should give a type error.

In my opinion, pursuing that idea would be a lot more valuable than
breaking BC for callables without much gain.

cheers
Dan
Ack
  108514
February 12, 2020 18:40 manuelcanga@gmail.com (Manuel Canga)
On Wed, 12 Feb 2020 at 15:08, Dan Ackroyd <Danack@basereality.com> wrote:

> On Tue, 11 Feb 2020 at 13:19, Nikita Popov ppv@gmail.com> wrote: > > > > https://wiki.php.net/rfc/consistent_callables. > > > > btw it's probably worth mentioning the other reason I didn't pursue > https://wiki.php.net/rfc/consistent_callables. > > By itself, the callable type isn't much use. It only allows you to > specify that a type can be called, but it doesn't allow you to specify > what parameters the callable should take, or what the return type > should be. > > Just making the callable type be consistent would be a lot of work, > and possibly cause a lot of BC breaks and still not do the useful > thing. > > Instead what would be far more useful would be allow people to define > the callable signature, and use that as a type. > > callable some_callback(int $x, string $y) : int; > > function bar(some_callback $fn) { } > > $fn_correct = function (int $x, string $y) : int {} > $fn_wrong = function (int $x, string $y) : int {} > > Calling bar with $fn_correct should work. > Calling bar with $fn_wrong should give a type error. > > In my opinion, pursuing that idea would be a lot more valuable than > breaking BC for callables without much gain. > > cheers > Dan > Ack >
Hi, internals, I think, we are taking this very far. In Spain, we usually say: "Quien mucho abarca, poco aprieta". In English, I think is similar to: "don’t bite off more than you can chew" or KISS/YAGNI in development. IMO, we should limit RFC to '::function'( scope and accept/reject ). After this, other RFC can be added/checked like Short closures( of Michal ) or other purposes with other variation like :interface and ::trait: ( of Mike ) Respect to ::function: ::function, it should return a string like ::class. This is: Case 1: ::function === \namespace\function_name ( when function_name is imported ) Case 2: ::function === \current_namespace\function_name( when ::function is below a namespace ) Case 3: ::function === \function_name( when ::function is not below a namespace ) Case 4: \namespace\::function === \namespace\function_name Case 5: \::function === \function_name ( equal of 4 but in global context ) Examples: 1. namespace my_project; use function \vendor\I18n\translate; $mapped_array = array_map(translate::function, $array); //= $mapped_array = array_map('\vendor\I18n\translate', $array); 2. namespace my_project; $mapped_array = array_map(translate::function, $array); //= $mapped_array = array_map('\my_project\translate' $array); 3. $mapped_array = array_map(translate::function, $array); //= $mapped_array = array_map('\translate' $array); 4. $mapped_array = array_map(\vendor\I18n\translate::function, $array); //= $mapped_array = array_map('\vendor\I18n\translate' $array); 5. $mapped_array = array_map(\translate::function, $array); //= $mapped_array = array_map('\translate' $array); Although, cases 3, 4 or 5, can appear useless, however editors could distinguish when is a function( and not a ordinary string ) and validate if function exists or not. Regards
  108515
February 12, 2020 18:45 mike@newclarity.net (Mike Schinkel)
> On Feb 12, 2020, at 1:40 PM, Manuel Canga <manuelcanga@gmail.com> wrote: > IMO, we should limit RFC to '::function'( scope and accept/reject ).
Agreed.
> After this, other RFC can be added/checked like Short closures( of Michal ) > or other purposes with other variation like :interface and ::trait: ( of Mike )
This feels a bit Handmaid's Tale-esque. But I digress... :-) -Mike