On Tue, 11 Feb 2020 at 13:16, Nicolas Grekas
nicolas.grekas+php@gmail.com wrote:

Le mar. 11 févr. 2020 à 12:52, Diogo Galvao diogo86@gmail.com a écrit :

Hi internals,
I Would like to present a possible new "::func resolution" for your
consideration.
...
use function \My\I18N\i18n_translate;

$mapped_array = array_map(i18n_translate::func, $array);
...
What is your opinion ? Do you see it useful ?

I've wished for this on many occasions and think it'd be really useful, as long
as it could work with methods as well:

$mapped_array = array_map(I18N::translate::function, $array);

For what it's worth I guess it could just return [I18N::class, 'translate'].

I wish this would return a Closure instead, making $foo::function the equivalent of Closure::fromCallable($foo).

Hi, Nicolas,

Currently, when <class_name>::class is used, class with <class_name>
can or cannot exists in that moment.
Using <function_name>::func( or <function_name>::function ), I think
should keep the same behavior.

Using ::func as alias of "Closure::fromCallable" check if function
exists in that moment. It is certainly useful, but, I think it's more
important be consistent

Checking whether the function exists is really unavoidable for functions, because you don't know whether

namespace Foo;
var_dump(strlen::function);

refers to 'Foo\strlen' or 'strlen', without first trying to look up the former.

I agree with Nicolas that this kind of feature would provide the most value if it created a Closure. This would circumvent all the issues outlined in https://wiki.php.net/rfc/consistent_callables.

Regards,
Nikita

Thanks, Nikita. I don't know that RFC.

In that case, why don't use ::callable ?. This will be useful for
functions and others callable. E.g:

enqueue_task([I18n::class, 'translate']::callable);
enqueue_task(translate::callable);

Would it be hard to implement in PHP ?

On Tue, Feb 11, 2020 at 1:43 PM Manuel Canga manuelcanga@gmail.com
wrote:

On Tue, 11 Feb 2020 at 13:16, Nicolas Grekas
nicolas.grekas+php@gmail.com wrote:

Le mar. 11 févr. 2020 à 12:52, Diogo Galvao diogo86@gmail.com a
écrit
:

On Tue, Feb 11, 2020 at 8:14 AM Manuel Canga manuelcanga@gmail.com
wrote:

Hi internals,
I Would like to present a possible new "::func resolution" for your
consideration.
...
use function \My\I18N\i18n_translate;

$mapped_array = array_map(i18n_translate::func, $array);
...
What is your opinion ? Do you see it useful ?

I've wished for this on many occasions and think it'd be really
useful,
as long
as it could work with methods as well:

$mapped_array = array_map(I18N::translate::function, $array);

For what it's worth I guess it could just return [I18N::class,
'translate'].

I wish this would return a Closure instead, making $foo::function the
equivalent of Closure::fromCallable($foo).

Hi, Nicolas,

Currently, when <class_name>::class is used, class with <class_name>
can or cannot exists in that moment.
Using <function_name>::func( or <function_name>::function ), I think
should keep the same behavior.

Using ::func as alias of "Closure::fromCallable" check if function
exists in that moment. It is certainly useful, but, I think it's more
important be consistent

Checking whether the function exists is really unavoidable for functions,
because you don't know whether

namespace Foo;
var_dump(strlen::function);

refers to 'Foo\strlen' or 'strlen', without first trying to look up the
former.

I agree with Nicolas that this kind of feature would provide the most value
if it created a Closure. This would circumvent all the issues outlined in
https://wiki.php.net/rfc/consistent_callables.

Regards,
Nikita

Can anyone thing of a use-case where you would want a string name of a
function and a callable would not be acceptable, besides possibly debugging
code that said 'echo "I'm calling ".myfunction::function;'? Everything that
I can think of that accepts a function name, also accepts a callable (e.g.
array_map), but I could be forgetting something.

If not, then I think it makes sense to return a callable. It might not be
entirely consistent with the behavior of ::class, but, a class isn't
entirely consistent with a method/function either, so I think there is some
latitude for small differences.

As for the ::func vs ::function. I think ::function is safer, since it's a
reserved word. Otherwise you might run into issues with something like this:

class foo {
const func = "bar";
}

function foo(){}

echo foo::func;

Probably not something that happens very often, but, I think the 4 extra
characters to prevent it would be worth it.

--
Chase Peeler
chasepeeler@gmail.com

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

wt., 11 lut 2020, 18:42 użytkownik Manuel Canga manuelcanga@gmail.com
napisał:

Nicolas Grekas wrote:

I wish this would return a Closure instead, making $foo::function the
equivalent of Closure::fromCallable($foo).

I didn't include the following in that RFC, because I thought it would
be too controversial, but I think it's worth considering a new syntax
for this.

Given the code:

function foo();
class Zoq {
public function Fot() {}
public static function Pik() {}
}
$obj = new Zoq();

Then these:

$(foo);
$($obj, Fot);
$(Zoq, Fot);

Would be equivalent to:

Closure::fromCallable('foo');
Closure::fromCallable([$obj, 'Fot']);
Closure::fromCallable('Zoq::Fot'); or Closure::fromCallable(['Zoq',
'Fot']);

Or similar.

The justification for having a dedicated syntax is that I think
readability is quite important in code, and it's reasonably common for
me to have quite long lists of 'callables'.

[Bar::class, foo1::function],
[Bar::class, foo2::function],
[Bar::class, foo3::function],
[Bar::class, foo4::function]

vs

$(Bar, foo1),
$(Bar, foo2),
$(Bar, foo3),
$(Bar, foo4)

The latter is far easier to read for me.

Nikita Popov wrote:

This would circumvent all the issues outlined in
https://wiki.php.net/rfc/consistent_callables.

Probably there would still be some issues with some of the weird stuff
happening internally in SPL related code where the deep horrors
rest...but we can leave them alone...and they might not wake.

cheers
Dan
Ack

Other option:

Closure::fromCallable('foo');
Closure::fromCallable([$obj, 'Fot']);
Closure::fromCallable('Zoq::Fot'); or Closure::fromCallable(['Zoq',
'Fot']);

to

<Foo> <$foo, Fot> <Zoq::Fot> <Zoq,'Fot>

E.g:

array_map(<strlen>, $array);
array_map(<I18n, Translate>, $array);

Do you like ?

That reminds me an old draft RFC https://wiki.php.net/rfc/short-closures
where I thought curly braces can be used to create closure from syntax
nearly the same as invoking but without parentheses.

That way we can provide clear intent - I mean if whatever is around: curly
braces or $ with parentheses IMHO it should be consistent with call like
format. For example:

$(strlen) or {strlen} for Closure::fromCallable('foo')

$($foo->Fot) or {$foo->Fot} for Closure::fromCallable([$obj, 'Fot'])

$(Zoq::Fot) or {Zoq::Fot} for Closure::fromCallable('Zoq::Fot')

Etc. The same inside like a call but wrapped in something and with no
parentheses part.

Cheers,

Michał Brzuchalski

$($obj->Fot);
However, wrapped inside $(), which only accepts
functions and methods

I don't think I meant that. I think it still should accept variables
as well, so it would still be ambiguous as to whether it referred to
the value of the property Fot of object $obj, or the method Fot on the
$obj class.

Also, just in general using something that has the same syntax as
current PHP code, but a different meaning, sounds like a bad idea.

another possibility could be: closure(foo);

That has the downside of exposing the implementation detail, that it's
implemented through closures, which would be a regrettable choice if
we ever decided to change the implementation details in the future.

And it also has the downside of looking like a function call, but
having different rules for what can be put inside it:

function foo();
closure(foo); // fine.
special_closure(foo); // syntax error, undefined constant foo.

Although avoiding new syntax is good in general, if what can go
inside it is different, then I think it requires a new syntax.

cheers
Dan
Ack

I would love a nicer way to reference function names; it's really ugly
to do functional code in PHP otherwise, or even just dynamic function
logic within a namespace. If I never have to write $fn = NAMESPACE
. '\a_func' again, it will be too soon. :-)

Perhaps Larry can convince us all to go for something like $() by
posting a fabulous functional programming example?

I walked right into that one, didn't I...

Well, Dik asked me to post a "fabulous functional programming example". I dont' have one, so I'll go with one from the book I'm working on instead. :-)

This is what I have now, assuming all global functions:

$result = Stats::of($string)
->analyze('normalizeNewlines')
->analyze('readingLevel')
->analyze('countStats')
->analyze(fn($s) => wordDistribution($s, 3))
;

I think we are all in agreement that is sub-optimal. If using functions in the Stats\Analyzer namespace, you end up with this:

$result = Stats::of($string)
->analyze('\Stats\Analyzer\normalizeNewlines')
->analyze('\Stats\Analyzer\readingLevel')
->analyze('\Stats\Analyzer\countStats')
->analyze(fn($s) => \Stats\Analyzer\wordDistribution($s, 3))
;

Or if you're in that namespace (as I often am) you can do:

$ns = NAMESPACE;

$result = Stats::of($string)
->analyze($ns . '\normalizeNewlines')
->analyze($ns . '\readingLevel')
->analyze($ns . '\countStats')
->analyze(fn($s) => \Stats\Analyzer\wordDistribution($s, 3))
;

This is doubleplusungood.

I'll expand the example to use some methods, too, for variety's sake:

$result = Stats::of($string)
->analyze('normalizeNewlines')
->analyze('readingLevel')
->analyze('countStats')
->analyze([$synonymSuggester, 'analyze'])
->analyze([WordCouter::class, 'analyze'])
->analyze(fn($s) => wordDistribution($s, 3))
;

As I understand it, the goal in this thread is to:

1. Make code like the above more statically analyziable by not using strings. (That covers a number of areas.)
2. Make code like the above easier to write by using symbols rather than strings.

In each case, the analyze() method wants a callable with a specific signature. Enforced callable signatures are absolutely something we desperately need, but are not the scope at the moment. In this example, then, that a function name is a string is incidental; what we care about is that it's callable. I don't have a good example off hand for it actually wanting a string, although strings are callables.

So, given this import block:

use Stats\Analyzer\normalizeNewlines;
use Stats\Analyzer\readingLevel;
use Stats\Analyzer\countStats;
use Stats\Analyzer\normalizeNewlines;
use Stats\Analyzer\wordDistribution;
use Stats\Analyzer\Stats;
use Stats\Analyzer\WordCounter;

here's the above example cast into a number of the different proposals floating about this thread:

::function

$result = Stats::of($string)
->analyze(normalizeNewlines::function)
->analyze(readingLevel::function)
->analyze(countStats::function)
->analyze([$synonymSuggester, 'analyze'])
->analyze([WordCouter::class, 'analyze'])
->analyze(fn($s) => wordDistribution($s, 3))
;

Analysis: I stand by my earlier statement that ::function is just too damned long for this funtionality. Not when already reserved shorter options exist.

::fn

$result = Stats::of($string)
->analyze(normalizeNewlines::fn)
->analyze(readingLevel::fn)
->analyze(countStats::fn)
->analyze([$synonymSuggester, 'analyze'])
->analyze([WordCouter::class, 'analyze'])
->analyze(fn($s) => wordDistribution($s, 3))
;

Analysis: Same thing, less typing.

::name

$result = Stats::of($string)
->analyze(normalizeNewlines::name)
->analyze(readingLevel::name)
->analyze(countStats::name)
->analyze([$synonymSuggester, 'analyze'])
->analyze([WordCouter::name, 'analyze'])
->analyze(fn($s) => wordDistribution($s, 3))
;

Analysis: This one gives us unification between classes and functions. I think that would be good, although it's not a hard requirement for the functionality.

Any of the above could be expanded, potentially, to include methods, like so:

::name, for methods, too

$result = Stats::of($string)
->analyze(normalizeNewlines::name)
->analyze(readingLevel::name)
->analyze(countStats::name)
->analyze([$synonymSuggester, analyze::name])
->analyze([WordCouter::name, analyze::name])
->analyze(fn($s) => wordDistribution($s, 3))
;

However, that requires the parser being able to tell the difference between analyze::name inside a callable array and not. That's... potentially complicated, since you can also just have an array that contains both objects and strings, or objects and callables, especially as objects can also be callables with __invoke().

$() or variations thereof

$result = Stats::of($string)
->analyze($(normalizeNewlines))
->analyze($(readingLevel))
->analyze($(countStats))
->analyze($($synonymSuggester, 'analyze'))
->analyze($(WordCouter::class, 'analyze'))
->analyze(fn($s) => wordDistribution($s, 3))
;

Analysis: I'm not sure I like this one, visually. "($(..))" feels like a lot of sigils soup. It also doesn't offer a way to deal with the method names in the object versions, unless we just assume that bare strings are allowed there, like so:

$result = Stats::of($string)
->analyze($(normalizeNewlines))
->analyze($(readingLevel))
->analyze($(countStats))
->analyze($($synonymSuggester, analyze))
->analyze($(WordCouter::class, analyze))
->analyze(fn($s) => wordDistribution($s, 3))
;

I will say that, given the behavior of ::class now, ::fn or ::name "feel like" they should return a string, whereas $() "feels like" it should return a callable, or something richer than a string. That's naturally subjective but is consistent with ::foo being a constant value and $() being, um, jQuery.

Also suggested was this:

closure()

$result = Stats::of($string)
->analyze(closure(normalizeNewlines))
->analyze(closure(readingLevel))
->analyze(closure(countStats))
->analyze(closure($synonymSuggester->analyze))
->analyze(closure(WordCouter::analyze))
->analyze(fn($s) => wordDistribution($s, 3))
;

Which aside from being verbose really does look an awful lot like a function call, and is how I'd interpret it. That said, a syntax that would recognize $foo->bar as a callable, not an invocation, and Foo::bar as a callable, would be really nice.

Of course... I feel compelled to ask why we can't just use bare function names. Treating a bare string as a string has been deprecated for several versions. If we remove that in PHP 8 and instead let it mean constant, then function, then class name, the following would become legal:

$result = Stats::of($string)
->analyze(normalizeNewlines)
->analyze(readingLevel)
->analyze(countStats)
->analyze([$synonymSuggester, analyze])
->analyze([WordCouter, analyze])
->analyze(fn($s) => wordDistribution($s, DISTRIBUTION_LIMIT))
;

Which would be much more in line with how many other languages handle symbol names. (There is likely some engine reason why it's way harder than I make it sound; I'd love to hear what that is so I know not to suggest it again, unless it really is that simple in which case...)

In all, I don't think there's a clear obvious winner here. All of the options have some kind of trade-off. My own preferences lean toward:

1. Keep it short; we don't need more long words.
2. No more parentheses; in context, there will be ample parentheses already anywhere a function is being referenced as a callable, so let's not drift more toward LISP. (This is why I don't think "well wrap it in fromCallable()" is a good answer.)
3. Handling method callables at the same time is not required, but would be really good for a complete solution.

--Larry Garfield