Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93256
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.52 as permitted sender)
To: Larry Garfield <larry@garfieldtech.com>, internals@lists.php.net
References: <CAESVnVpa5j=fagr-wm5+DzKKX=wzTN1p8+Kv3-KtGpuyH51b0A@mail.gmail.com>
 <0ac3be89-6fb4-610a-ef89-0928f264f96c@fleshgrinder.com>
 <CAESVnVpBn2fpK-BQXj2261mTMG7ZUK1XwOS6jZn1wiYBEs61mg@mail.gmail.com>
 <71379db5-b7b8-78b3-ada5-eee34e6e22d6@fleshgrinder.com>
 <CAObuZdtS-gn3gT6L2bwshF4H9KzxZSaCsu41CYtyeT+=SOCSyg@mail.gmail.com>
 <a25612f2-fb09-c25e-ca30-daf850acaa96@fleshgrinder.com>
 <CAObuZduo2-mnZMbgKFEWN1=yxqgqh_8RCN7GSpCTYCNXVjWJ_w@mail.gmail.com>
 <fe837e8b-2a6e-516e-33f0-cfcca172d565@fleshgrinder.com>
 <CAGa2bXaKWu+WJ7unZ2TfG03KUYY3JyNG=FK3cUbR3PL244znyA@mail.gmail.com>
 <ddcfc338-a2fb-a06f-36ef-30e105772779@gmail.com>
 <CAESVnVr07J9UF3Dh7a1rMudMmQjeYuayvoT8Rmde+rfCBK6vnQ@mail.gmail.com>
 <452ddb93-1f47-1d0f-4f24-bedbff506b27@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>
Message-ID: <0e5e2ac8-c003-7000-ecdd-bef6b430e525@gmail.com>
Date: Wed, 11 May 2016 16:49:18 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0)
 Gecko/20100101 Thunderbird/45.0
MIME-Version: 1.0
In-Reply-To: <1463008795.1856219.605250569.74618FC4@webmail.messagingengine.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Pipe Operator
From: smalyshev@gmail.com (Stanislav Malyshev)

Hi!


> If the issue is $$ feels too Perl like, what is the alternative?  Is
> there another way to chain methods cleanly?

Well, that's a loaded question. It presumes we already agreed on needing
to chain methods using special syntax outlined in the RFC - which we
didn't - and the only problem is whether it's $$ or $* or @% or some
other sequence of symbols. I'm not convinced at all of the premise, so
discussing which exactly two characters should be used for $$ does not
really appeal to me.

> In a sense, what we're really talking about here is continuations. 

Not sure how it's continuations:
https://en.wikipedia.org/wiki/Continuation

If anything, generators look like continuations. This just looks like
fancy way to write sequence of function calls with novel syntax. Do you
mean something else by "continuations"? Or I missed some part of the RFC?

> a series of single parameter functions.  So what if we were to limit the
> concurrency syntax to single-parameter functions?  And if you want to
> reduce a multi-parameter function to a single parameter function, yay
> closures.

I'm not sure where "concurrency syntax" comes from. What's concurrent here?

> Either way, I firmly believe that more functional-friendly capabilities
> like continuations, promises, etc. are a direction that PHP needs to
> move, and syntax in that direction is valuable.

I'm not sure that's where PHP *needs* to move, but we already have
continuations, as I mentioned. As for other async capabilities like
promises/futures, that may be possible but there are some hard questions
need to be answered here because PHP is not well suited for environment
sharing.

I also am not sure functional syntax is well suited for PHP, given that
PHP is not a functional language and vast majority on PHP code is not
written in functional manner. Functional programming requires quite
different approach than most PHP applications take, and frankly I'm not
sure why this should change - there are enough functional languages around.

Of course, that doesn't mean avoiding *all* functional features - some
of them make total sense even in non-functional language, like closures
or functions like map/reduce/filter. Some, however, are harder to fit.
-- 
Stas Malyshev
smalyshev@gmail.com