Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108549
User-Agent: Cyrus-JMAP/3.1.7-802-g7a41c81-fmstable-20200203v1
Mime-Version: 1.0
Message-ID: <d494ed31-f5c5-4946-a7f8-75a03027a0ee@www.fastmail.com>
In-Reply-To: <2C404984-AD76-4CDF-8E1A-04DF8EF024DD@newclarity.net>
References: 
 <CAD5P3=JwFK03L-DWJYaa0dbBj1chbef_=K-vyawLNeoAz7dHjA@mail.gmail.com>
 <CALSrLtYm+TSEwo+05JC6LXrQsfzb32pQ24Y7gDUmm-7+NwYi8w@mail.gmail.com>
 <CAOWwgpm43=hoCvsskq2qyhB3yVxntLAYC8hQjQwd9dnvQ=GKkg@mail.gmail.com>
 <CAD5P3=L8bQ4bp5i5f=SdOP-=Wmn6TSj6+4Jzw76WRwJ=89evtw@mail.gmail.com>
 <CAF+90c-myY2NeKcaTRH3zDcwxRC95RhKnm1MPTGN68WUq4RPAA@mail.gmail.com>
 <CAPKYkKy-NwDmpN_5Zet8Oz9JLVzu11PmODP6byBYuJry3TUvbg@mail.gmail.com>
 <CE981907-0CDD-421F-BC01-1B3F0E95B199@newclarity.net>
 <ebc970d9-8c70-9563-1792-fd8c7ef67f2f@gmail.com>
 <DE2D0FCB-4C39-43F4-B6B6-B5796271EB0E@newclarity.net>
 <10FCCCED-B8AE-4394-91B3-0FEB448E2398@gmail.com>
 <D368D433-A2AE-4C05-9341-A6F0502BF454@newclarity.net>
 <CALKiJKrHKiY0-4=ihES5Uw4OUinAmyNRaiNqQrX-x3Gj74mWDQ@mail.gmail.com>
 <2C404984-AD76-4CDF-8E1A-04DF8EF024DD@newclarity.net>
Date: Thu, 13 Feb 2020 12:48:23 -0600
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC]
From: larry@garfieldtech.com ("Larry Garfield")

On Thu, Feb 13, 2020, at 12:19 PM, Mike Schinkel wrote:
> > On Feb 13, 2020, at 12:26 PM, Rowan Tommins <rowan.collins@gmail.com=
> wrote:
> > Right, I'm with you now. However, I think the answer people are sugg=
esting
> > to "how do we get the name string?" is "why do we need to?"
>=20
> 1. Say I want to provide users with the ability to build queries and=20=

> use functions where I want to provide the names of the functions to th=
e=20
> users:
>=20
> $qt =3D QueryTool();
> $qt->addFunction(substr::function);
> $qt->addFunction(add_product::function);
> $qt->showUI();
>=20
> 2. Say I want to serialize any configuration that uses functions.  You=
=20
> can't serialize closures but you can serialize function names to a=20
> database or JSON.
>=20
> 3. You cannot use a closure as an array index so if you want to use th=
e=20
> function name as an array key to associate additional information to=20=

> the use with the function, such as:
>=20
> $qt =3D QueryTool();
> $qt->addFunction(substr::function, array(=20
> 	new FuncParam( 'string', 'string' ),
> 	new FuncParam( 'int', 'start', QueryTool::Optional ),
> 	new FuncParam( 'int', 'length', QueryTool::Optional )
> ));
> $qt->addFunction(add_product::function, array(=20
> 	new FuncParam( 'string', 'product_id' ),
> 	new FuncParam( 'float', 'price' )
> ));

Those are valid examples.  I suppose along similar lines would be toolin=
g that uses a builder to generate compiled code.  (Eg, if $qt were used =
to then generate an optimized function in a class on disk.)

Flipside: In those cases we really should standardize static methods bet=
ter than with arrays, yet none of these address (nor can they) instance =
methods.

> 4. Being able to compose quality error and warning message that includ=
e=20
> function names.
>=20
> > Or as Chase Peeler more eloquently put it:
> >=20
> >> Can anyone think of a use-case where you would want a string name o=
f a
> >> function and a callable would not be acceptable, besides possibly d=
ebugging
> >> code that said 'echo "I'm calling ".myfunction::function;'? Everyth=
ing that
> >> I can think of that accepts a function name, also accepts a callabl=
e (e.g.
> >> array_map), but I could be forgetting something.
>=20
> Eloquently maybe, but of limited vision.
>=20
>=20
> > There's a Venn diagram, essentially, of:
> > a) use cases where a Closure would be useful, but a string wouldn't
> > b) use cases where a string would be useful, but a Closure wouldn't
> > c) use cases where either a string or a Closure would be useful
> >=20
> > If (and it's a genuine open question) all the use cases fall into
> > categories (a) and (c), we can make the syntax for closures simpler =
by
> > skipping the "get name" step and making foo::fn return a closure str=
aight
> > away.
> >=20
> > So the question is, are there use cases that fall into category (b)?=

>=20
> Yes. Definitely.

I agree, the above examples demonstrate valid use cases for (b).

> But since I seem to be in the minority of caring about the name, let m=
e=20
> propose the following which was influenced by Larry Garfield's most=20=

> recent post.  Since it seems that people want the convenience of a=20
> short notation to get a closure, how about this:
>=20
> function foo{}
>=20
> foo::function  =E2=80=94 Returns name of function
> foo::fn  =E2=80=94 Returns closure for function=20
>=20
> Since using `fn` creates anonymous function closures it kinda makes=20=

> sense that `::fn` would return a closure.
>=20
> -Mike

thinking-face-emoji.gif.  I could be convinced of that.  It seems like "=
both" is a possible solution, but my concern would be someone using one =
of them in a case where either works, inadvertently, when the callee is =
expecting just one.  Eg, getting into the habit of using foo::fn, and th=
en using it on a builder routine that chokes "later" when it tries to se=
rialize something.

--Larry Garfield