Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93371
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.218.45 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <0d264480-3e55-4765-d6db-eec8dfcb47bf@php.net>
References: <CAESVnVpa5j=fagr-wm5+DzKKX=wzTN1p8+Kv3-KtGpuyH51b0A@mail.gmail.com>
	<CAESVnVqohR7rkaJASZ0rFuAD6GEiasqbAak-fJB3+K2vSKqHFQ@mail.gmail.com>
	<98.61.11104.A1D41375@pb1.pair.com>
	<7c94ca37-e188-dd2b-a66f-bb63bf03041a@gmail.com>
	<1463008795.1856219.605250569.74618FC4@webmail.messagingengine.com>
	<CANaX5nekRmhNKmY78tHRrev0_B3a-faRsQ8Jf=yA-jCkEP5-Ew@mail.gmail.com>
	<CAKrrN64bu+T0Sv4V6mo7i1cRYAh1W8Kx8tQ_rqQmZagXBTqKuQ@mail.gmail.com>
	<92E7F8A8-0845-48A7-91B1-9554C5F66C9D@zend.com>
	<CAESVnVq14EL_hJ=G_QTpvbzQhxP-Auy5p2rH9yja8bABsVr_sQ@mail.gmail.com>
	<879feadf-c04e-c0de-826b-110b3eb4e22f@php.net>
	<CAESVnVoW8+c1iDHxc52o2cxhiuBn7Z5Ag0+hsh1xKv73kUbBNQ@mail.gmail.com>
	<ff1cb37c-923b-f9c6-e326-c75a4f3e1623@php.net>
	<CAESVnVrn6iSZ7KWVDpcJ-Fw7k9NZnUbHUs88RBOBPsENg_sVWQ@mail.gmail.com>
	<85ec320c-b8d6-1cc8-2059-7b8dfa6589e2@php.net>
	<5739237C.1090605@garfieldtech.com>
	<33119a72-a146-ea6a-076a-67a886ebdaea@php.net>
	<CAESVnVqAXDHJFjVXvRF1s5aUtz3Hf8-6mRQSPPCovLGxL+SQxw@mail.gmail.com>
	<0d264480-3e55-4765-d6db-eec8dfcb47bf@php.net>
Date: Tue, 17 May 2016 06:47:07 -0600
Message-ID: <CAObuZdsRYXhN2wMWS3jwVV-nifmCdDh56c4LGM9f5484S=2=_g@mail.gmail.com>
To: =?UTF-8?Q?Fran=C3=A7ois_Laupretre?= <francois@php.net>
Cc: Sara Golemon <pollita@php.net>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a1140a5b29538a6053309236a
Subject: Re: [PHP-DEV] [RFC] Pipe Operator
From: derokorian@gmail.com (Ryan Pallas)

--001a1140a5b29538a6053309236a
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tue, May 17, 2016 at 6:15 AM, Fran=C3=A7ois Laupretre <francois@php.net>
wrote:
>
>
>
>> The question of function aliases is not so serious because we'll need ve=
ry
>>> few. Almost every functions have only one 'natural' argument to
>>> substitute
>>> as lhs. I'm not sure I understand what you mean with 'but only in certa=
in
>>> situations'.
>>>
>>> If it were so natural, wouldn't the original version of these
>> functions have been made "right" in the first place?  I fear that the
>> only thing we'd gain by adding all these aliases is more functions,
>> but without the benefit of any improvement in the argument ordering
>> problem because now, instead of remembering which order the argument
>> is in, users have to remember which alias to call.
>>
>
> Right. That's why I propose we start without creating any function alias.
> We're not supposed to allow writing anything in a pipeline. For every
> functions, the substituted argument will always be the
> haystack|subject|source|input argument. That's easy to remember.
>

Which I don't think covers many use cases that the Pipe Operator would
currently solve. Doing this would lessen its usefulness IMO. Think about
common string nesting like:

$var =3D substr($var, 0, strpos($var, $othervar));

With current Pipe it would be:

$var =3D strpos($var, $othervar)
   |> substr($var, 0, $$);

but your suggestion requires this be kept nested as only haystack is
allowed? That totally weakens the proposal in my book.

@Sara: Can the place holder be used twice? If its numeric, can I make it
negative or perform other math? I don't see anything in the RFC allowing or
disallowing such things. Such as:

$var =3D strlen($str)
    |> substr($var, -$$, $$/2)

--001a1140a5b29538a6053309236a--