Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93000
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.171 as permitted sender)
To: Larry Garfield <larry@garfieldtech.com>, internals@lists.php.net
References: <CAESVnVpa5j=fagr-wm5+DzKKX=wzTN1p8+Kv3-KtGpuyH51b0A@mail.gmail.com>
 <8ea990da-1fe7-256c-4e08-0b30715c8e8a@gmail.com>
 <5724F3F8.5070909@garfieldtech.com>
Message-ID: <5637f0b4-c72f-688b-f799-21b8ecc3dc18@gmail.com>
Date: Sat, 30 Apr 2016 12:43:48 -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: <5724F3F8.5070909@garfieldtech.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Pipe Operator
From: smalyshev@gmail.com (Stanislav Malyshev)

Hi!

> See, I take that quote in the exact opposite direction.  I find chaining
> methods to be far, far less "clever" than deeply nesting them inside

If you tell me that syntax like "foo() |> bar($$)" is more natural or
intuitive or readily understandable to anyone with any programming and
PHP background than "$fooResult = foo(); bar($fooResult); " then we
indeed have exactly opposite understanding of what is natural and intuitive.

I think that overly clever is inventing cryptic syntax to save a couple
of keystrokes and rearrange code in unusual pattern that looks unlike
the code used to look before and resembles some other language (this
time it's F#? how many languages PHP should be at once - can we get a
dozen?)

> each other.  We shouldn't force pointless intermediate variables on

Why you think they are pointless? And you do produce them, you just hide
them behind $$ so you can not actually neither check them nor understand
which value goes where without tracing through the code with your finger.

> people for the sake of readability.  The fair comparison is the deeply
> nested version vs. the chained version, and in that comparison the
> readability of the chained version is far, far better.

No, it's not a fair comparison. You shouldn't do deep nesting, and you
shouldn't do cryptic syntax either. Variables are not evil. They are
there to make things easier for you. Use them.

> intermediate variable to analyze and nothing has changed.  However,
> passing an array to array_filter() then passing the result to
> array_map() is always type safe (because array_filter still returns an
> array even if it filters down to 0 items), and array_map on an empty
> array is essentially a no-op, so I'm comfortable doing so, and wish I
> could do so more often with less fugly syntax. :-)

I appreciate the careful choice of the example on RFC - indeed, in some
very carefully chosen cases (mostly with arrays) you could get away with
chaining without getting into trouble. In most cases where it would be
used, though, that would mean not checking for errors, forgetting corner
cases and so on. And that's how people would use this, because none of
the existing functions were developed to work with this pattern, so you
can only get away with it due to luck.

In strictly typed languages like Haskell, they use types like Option and
Maybe to enable this pattern - essentially, to enable functions to
operate on more than one simple type of value. However, it doesn't look
in place in PHP, and it would require much more deep restructuring to
actually make it work than just having |> as an operator.

> of promises", but more "is there something we can do here to be forward
> thinking, since lots of people want to see async in core PHP?")

I'm not sure what promises have to do with inventing strange syntax to
pass result of one function as a parameter to another.
-- 
Stas Malyshev
smalyshev@gmail.com