Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108463
MIME-Version: 1.0
References: <CAD5P3=JwFK03L-DWJYaa0dbBj1chbef_=K-vyawLNeoAz7dHjA@mail.gmail.com>
 <1581420814.35391.0@inventis.be>
In-Reply-To: <1581420814.35391.0@inventis.be>
Date: Tue, 11 Feb 2020 12:47:05 +0100
Message-ID: <CAD5P3=++DHCWCDnbPoZ=AqKignL8=gwykz9GkumnJm3=T6C5+g@mail.gmail.com>
To: Tom Gerrits <tom@inventis.be>
Cc: internals@lists.php.net
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] [RFC]
From: manuelcanga@gmail.com (Manuel Canga)

Hi Tom,

I thought about that short version. However, in order to avoid
conflicts with constants, I chosen "::func". If this is not problem in
low level of PHP, then I agree with you in shorter version is better.

Thanks for your opinion, Tom





On Tue, 11 Feb 2020 at 12:33, Tom Gerrits <tom@inventis.be> wrote:
>
> Hi Manuel
>
> Thanks for bringing this idea forward.
>
> Adding a non-string construct to reference functions uniquely seems
> like a good idea and would be consistent with the existing ::class
> keyword for classes.
>
> I'm wondering if it would be useful to take a page out of the book of
> other programming languages in order to shorten the notation further:
>
> > // First file.
> > namespace A\B;
> >
> > function foo() { }
> >
> > // Second file.
> > use function A\B\foo;
> >
> > function bar(callable $c) { }
> >
> >
> > // Current approach.
> > bar('\A\B\foo');
> >
> > // Notation without parantheses, references imported function.
> > // Similarly, in the future, Class::method could reference a
> > // class method.
> > bar(foo);
> >
> > // Notation with references, could be expanded in the future
> > // for static class methods, such as &Class::method.
> > bar(&foo);
>
> The second example can already be achieved by defining your own
> constant that references the fully qualified name and importing it.
> However, an explicit, separate, import of these constants is still
> needed, which is not ideal.
>
> A suffix "::func" would also be useful, but allowing shorter notation
> would improve readability when using the functional programming
> paradigm and composing functions.
>
> Op di, feb 11, 2020 at 12:13 schreef Manuel Canga
> <manuelcanga@gmail.com>:
> > Hi internals,
> > I Would like to present a possible new "::func resolution" for your
> > consideration.
> >
> > In first place, PHP now support "::class" in this way:
> >
> > use My\I18N;
> >
> > $mapped_array = array_map([I18N::class, 'translate'], $array);
> > It avoid add Full I18N  namespace in callback.
> >
> > However with functions is different:
> >
> > use function \My\I18N\i18n_translate;
> >
> > $mapped_array = array_map('\My\I18N\i18n_translate', $array);
> >
> > What is the useful here of importing the function?.
> > My proposal is ":func" in order to avoid full namespace in callback of
> > functions. E.g:
> >
> > use function \My\I18N\i18n_translate;
> >
> > $mapped_array = array_map(i18n_translate::func, $array);
> >
> > "<string>::func" should validate if a function with `<string>` is
> > imported.
> > In this case, "<string>::func" is replaced with FQN of this function,
> > otherwise with only "<string>"
> >
> > What is your opinion ? Do you see it useful ?
> >
> > Thanks and I'm sorry for my English( I'm a Spanish ).
> >
> > Regards
>
>