Re: [PHP-DEV] [RFC] Pipe Operator, take 2

Just to clarify, I said it didn't look like it could be a pure AST implementation, and that it looks like you may need one additional instruction. It does look that way to me - if only to throw a sensible error specifically for pipes but also because it makes the imposition of specific behaviour

Re: [PHP-DEV] [RFC] Pipe Operator, take 2

On Mon, Jul 5, 2021, at 11:05 AM, Larry Garfield wrote: > On Sat, Jul 3, 2021, at 9:12 PM, Larry Garfield wrote: > > On Mon, Jun 7, 2021, at 2:00 PM, Larry Garfield wrote: > > > Hi folks. Me again. > > > > > > A year ago, I posted an RFC for a pipe operator, |>, aka function > > > concatenation.

Re: [PHP-DEV] [RFC] Pipe Operator, take 2

On Sat, Jul 3, 2021, at 9:12 PM, Larry Garfield wrote: > On Mon, Jun 7, 2021, at 2:00 PM, Larry Garfield wrote: > > Hi folks. Me again. > > > > A year ago, I posted an RFC for a pipe operator, |>, aka function > > concatenation. At the time, the main thrust of the feedback was "cool, > > like,

Re: [PHP-DEV] [RFC] Pipe Operator, take 2

On Sun, Jul 4, 2021, at 2:18 AM, Olle Härstedt wrote: > 2021-07-04 4:12 GMT+02:00, Larry Garfield : > > On Mon, Jun 7, 2021, at 2:00 PM, Larry Garfield wrote: > >> Hi folks. Me again. > >> > >> A year ago, I posted an RFC for a pipe operator, |>, aka function > >> concatenation. At the time, the

Re: [PHP-DEV] [RFC] Pipe Operator, take 2

2021-07-04 4:12 GMT+02:00, Larry Garfield : > On Mon, Jun 7, 2021, at 2:00 PM, Larry Garfield wrote: >> Hi folks. Me again. >> >> A year ago, I posted an RFC for a pipe operator, |>, aka function >> concatenation. At the time, the main thrust of the feedback was "cool, >> like, but we need

Re: [PHP-DEV] [RFC] Pipe Operator, take 2

On Mon, Jun 7, 2021, at 2:00 PM, Larry Garfield wrote: > Hi folks. Me again. > > A year ago, I posted an RFC for a pipe operator, |>, aka function > concatenation. At the time, the main thrust of the feedback was "cool, > like, but we need partial function application first so that the syntax

Re: [PHP-DEV] [RFC] Pipe Operator, take 2

2021-06-29 0:54 GMT+02:00, Larry Garfield : > On Mon, Jun 28, 2021, at 5:30 PM, Olle Härstedt wrote: > >> Mm. Assoc arrays are by now known to be not so good. I hope... > > There are millions of PHP sites build on anonymous arrays today. > >> OCaml is strictly evaluated, not lazy like Haskell. So

Re: [PHP-DEV] [RFC] Pipe Operator, take 2

> I talked with Joe about this, and the answer is no. Most of the complexity > comes from the initial "this is a function call, oops no, it's a partial > call so we switch to doing that instead", which ends up interacting with the > engine in a lot of different places. Once you've done that,

Re: [PHP-DEV] [RFC] Pipe Operator, take 2

On Mon, Jun 28, 2021, at 5:30 PM, Olle Härstedt wrote: > Mm. Assoc arrays are by now known to be not so good. I hope... There are millions of PHP sites build on anonymous arrays today. > OCaml is strictly evaluated, not lazy like Haskell. So the order might > matter, dunno, I don't use this

Re: [PHP-DEV] [RFC] Pipe Operator, take 2

2021-06-29 0:06 GMT+02:00, Rowan Tommins : > On 28/06/2021 21:28, Olle Härstedt wrote: >> Sorry for hijacking the thread, but are there no other alternatives, >> really? Just brainstorming: >> >> 1) Setting to silence the warning. > > > Just to reiterate: in PHP 8.0, an undefined constant is not a

Re: [PHP-DEV] [RFC] Pipe Operator, take 2

2021-06-28 23:36 GMT+02:00, Larry Garfield : > On Mon, Jun 28, 2021, at 3:42 PM, Olle Härstedt wrote: >> 2021-06-28 22:12 GMT+02:00, Larry Garfield : >> > On Mon, Jun 28, 2021, at 3:04 PM, Rowan Tommins wrote: >> >> On 28/06/2021 20:25, Olle Härstedt wrote: >> >> > Usage (ignoring the pesky

Re: [PHP-DEV] [RFC] Pipe Operator, take 2

On 28/06/2021 21:28, Olle Härstedt wrote: Sorry for hijacking the thread, but are there no other alternatives, really? Just brainstorming: 1) Setting to silence the warning. Just to reiterate: in PHP 8.0, an undefined constant is not a warning, it's an error. My apologies to code golfers:

Re: [PHP-DEV] [RFC] Pipe Operator, take 2

On Mon, Jun 28, 2021, at 3:42 PM, Olle Härstedt wrote: > 2021-06-28 22:12 GMT+02:00, Larry Garfield : > > On Mon, Jun 28, 2021, at 3:04 PM, Rowan Tommins wrote: > >> On 28/06/2021 20:25, Olle Härstedt wrote: > >> > Usage (ignoring the pesky undefined constant warnings ><): > >> > >> > >>

Re: [PHP-DEV] [RFC] Pipe Operator, take 2

2021-06-28 22:12 GMT+02:00, Larry Garfield : > On Mon, Jun 28, 2021, at 3:04 PM, Rowan Tommins wrote: >> On 28/06/2021 20:25, Olle Härstedt wrote: >> > Usage (ignoring the pesky undefined constant warnings ><): >> >> >> Unfortunately, you can't ignore those warnings; not least because >> they're

Re: [PHP-DEV] [RFC] Pipe Operator, take 2

2021-06-28 22:04 GMT+02:00, Rowan Tommins : > On 28/06/2021 20:25, Olle Härstedt wrote: >> Usage (ignoring the pesky undefined constant warnings ><): > > > Unfortunately, you can't ignore those warnings; not least because > they're fatal errors in PHP 8, as they frankly should have been in PHP 3.

Re: [PHP-DEV] [RFC] Pipe Operator, take 2

On Mon, Jun 28, 2021, at 3:04 PM, Rowan Tommins wrote: > On 28/06/2021 20:25, Olle Härstedt wrote: > > Usage (ignoring the pesky undefined constant warnings ><): > > > Unfortunately, you can't ignore those warnings; not least because > they're fatal errors in PHP 8, as they frankly should have

Re: [PHP-DEV] [RFC] Pipe Operator, take 2

On 28/06/2021 20:25, Olle Härstedt wrote: Usage (ignoring the pesky undefined constant warnings ><): Unfortunately, you can't ignore those warnings; not least because they're fatal errors in PHP 8, as they frankly should have been in PHP 3. You can use our current ugly callable syntax

Re: [PHP-DEV] [RFC] Pipe Operator, take 2

2021-06-07 21:00 GMT+02:00, Larry Garfield : > Hi folks. Me again. > > A year ago, I posted an RFC for a pipe operator, |>, aka function > concatenation. At the time, the main thrust of the feedback was "cool, > like, but we need partial function application first so that the syntax for >

Re: [PHP-DEV] [RFC] Pipe Operator, take 2

On Tue, Jun 8, 2021 at 4:09 PM Larry Garfield wrote: > On Tue, Jun 8, 2021, at 5:41 AM, Guilliam Xavier wrote: > > > you forgot to update one > > `explode(?)` to `str_split(?)`, and also, the first `fn($v) => > > 'strtoupper'` should be just `'strtoupper'`. > > I deliberately made that example

Re: [PHP-DEV] [RFC] Pipe Operator, take 2

On Tue, Jun 8, 2021, at 5:41 AM, Guilliam Xavier wrote: > > Hm. You're right. It used to, but it's been a very long time since > > explode() allowed an empty split, apparently. I updated the example to use > > str_split, which is what I'd intended to do in this case. Thanks. > > > > Are you

Re: [PHP-DEV] [RFC] Pipe Operator, take 2

Hi, On Tue, Jun 8, 2021 at 12:09 AM Larry Garfield wrote: > On Mon, Jun 7, 2021, at 4:00 PM, Eugene Leonovich wrote: > > On Mon, Jun 7, 2021 at 9:03 PM Larry Garfield > > wrote: > > > > > https://wiki.php.net/rfc/pipe-operator-v2 > > > > > FTR, there are several typos in the "Hello World"

Re: [PHP-DEV] [RFC] Pipe Operator, take 2

> On Jun 7, 2021, at 9:39 PM, Larry Garfield wrote: > > On Mon, Jun 7, 2021, at 8:09 PM, Mike Schinkel wrote: >> >>> On Jun 7, 2021, at 3:00 PM, Larry Garfield wrote: >>> >>> Hi folks. Me again. >>> >>> A year ago, I posted an RFC for a pipe operator, |>, aka function >>> concatenation. At

Re: [PHP-DEV] [RFC] Pipe Operator, take 2

On Mon, Jun 7, 2021, at 8:09 PM, Mike Schinkel wrote: > > > On Jun 7, 2021, at 3:00 PM, Larry Garfield wrote: > > > > Hi folks. Me again. > > > > A year ago, I posted an RFC for a pipe operator, |>, aka function > > concatenation. At the time, the main thrust of the feedback was "cool, > >

Re: [PHP-DEV] [RFC] Pipe Operator, take 2

> On Jun 7, 2021, at 3:00 PM, Larry Garfield wrote: > > Hi folks. Me again. > > A year ago, I posted an RFC for a pipe operator, |>, aka function > concatenation. At the time, the main thrust of the feedback was "cool, like, > but we need partial function application first so that the

Re: [PHP-DEV] [RFC] Pipe Operator, take 2

On Mon, Jun 7, 2021, at 4:00 PM, Eugene Leonovich wrote: > On Mon, Jun 7, 2021 at 9:03 PM Larry Garfield > wrote: > > > Hi folks. Me again. > > > > A year ago, I posted an RFC for a pipe operator, |>, aka function > > concatenation. At the time, the main thrust of the feedback was "cool, > >

Re: [PHP-DEV] [RFC] Pipe Operator, take 2

On Mon, Jun 7, 2021 at 9:03 PM Larry Garfield wrote: > Hi folks. Me again. > > A year ago, I posted an RFC for a pipe operator, |>, aka function > concatenation. At the time, the main thrust of the feedback was "cool, > like, but we need partial function application first so that the syntax for

[PHP-DEV] [RFC] Pipe Operator, take 2

Hi folks. Me again. A year ago, I posted an RFC for a pipe operator, |>, aka function concatenation. At the time, the main thrust of the feedback was "cool, like, but we need partial function application first so that the syntax for callables isn't so crappy." The PFA RFC is winding down now

Re: [PHP-DEV] [RFC] Pipe Operator

On 17/05/2016 18:46, Sara Golemon wrote: On Tue, May 17, 2016 at 4:14 AM, Rowan Collins > wrote: >> On 17/05/2016 11:55, Jesse Schalken wrote: $id |> >> StringList::decode($$) |> array_replace($$, $replace) |> >> StringList::encode($$) |> $id; >> >> >> Sara, what do

Re: [PHP-DEV] [RFC] Pipe Operator

On Tue, May 17, 2016 at 5:47 AM, Ryan Pallas wrote: > Can the place holder be used twice? > In the current PR version, no. It adds complexity to the implementation when dealing with temp vars. In the interest of keeping the implementation simple, I opted for making the

Re: [PHP-DEV] [RFC] Pipe Operator

On Tue, May 17, 2016 at 4:14 AM, Rowan Collins wrote: > On 17/05/2016 11:55, Jesse Schalken wrote: > $id > |> StringList::decode($$) > |> array_replace($$, $replace) > |> StringList::encode($$) > |> $id; > > > Sara, what do you think of this tweak, and my

Re: [PHP-DEV] [RFC] Pipe Operator

On 17/05/2016 13:48, Jesse Schalken wrote: On Tue, May 17, 2016 at 9:14 PM, Rowan Collins > wrote: To reiterate my comments from earlier in the thread, I think the "$id = $id" looks really weird here, and spoils the step-by-step

Re: [PHP-DEV] [RFC] Pipe Operator

On Tue, May 17, 2016 at 9:14 PM, Rowan Collins wrote: > To reiterate my comments from earlier in the thread, I think the "$id = > $id" looks really weird here, and spoils the step-by-step layout - and, in > this case, the symmetry. > We have the same thing already when

Re: [PHP-DEV] [RFC] Pipe Operator

On Tue, May 17, 2016 at 6:15 AM, François Laupretre wrote: > > > >> The question of function aliases is not so serious because we'll need very >>> few. Almost every functions have only one 'natural' argument to >>> substitute >>> as lhs. I'm not sure I understand what you mean

Re: [PHP-DEV] [RFC] Pipe Operator

Le 16/05/2016 à 19:53, Sara Golemon a écrit : I think you're making a false equivalence here. One can see argument ordering consistency as a serious problem without seeing a Heath Robinson version of call chaining as the solution to it. I appreciate that you want to seize onto any opportunity

Re: [PHP-DEV] [RFC] Pipe Operator

On 17/05/2016 11:55, Jesse Schalken wrote: $id = $id |> StringList::decode($$) |> array_replace($$, $replace) |> StringList::encode($$); To reiterate my comments from earlier in the thread, I think the "$id = $id" looks really weird here, and spoils the step-by-step layout - and,

Re: [PHP-DEV] [RFC] Pipe Operator

Not sure if it's already been mentioned, but I've noticed this operator would be useful when you want to modify something but need to transform it before and after. For example, I have a class that serializes/deserializes arrays of strings, and I need to modify the array that it has encoded. The

Re: [PHP-DEV] [RFC] Pipe Operator

Hi Sara, On Apr 30, 2016 3:11 AM, "Sara Golemon" wrote: > > This is one of my favorites out of HackLang. It's pure syntactic > sugar, but it goes a long way towards improving readability. > https://wiki.php.net/rfc/pipe-operator After I first read the rfc my immediate feeling

Re: [PHP-DEV] [RFC] Pipe Operator

On Mon, May 16, 2016 at 2:17 AM, François Laupretre wrote: > Le 16/05/2016 à 03:33, Larry Garfield a écrit : >> This still sounds awfully complicated to me. I would far, far prefer >> the $$ syntax to special casing function aliases just to dance around >> it. If we had a

Re: [PHP-DEV] [RFC] Pipe Operator

Le 16/05/2016 à 03:33, Larry Garfield a écrit : This still sounds awfully complicated to me. I would far, far prefer the $$ syntax to special casing function aliases just to dance around it. If we had a short-function syntax then requiring a piped function to have only a single argument would

Re: [PHP-DEV] [RFC] Pipe Operator

On 05/14/2016 07:42 PM, François Laupretre wrote: Le 13/05/2016 à 20:16, Sara Golemon a écrit : for a potential solution to such a long-time issue as argument ordering sadness, IMHO, it's worth the pain. I am currently doing it and I'll send you the list when it is ready. Awesome. Even if

Re: [PHP-DEV] [RFC] Pipe Operator

Le 13/05/2016 à 20:16, Sara Golemon a écrit : for a potential solution to such a long-time issue as argument ordering sadness, IMHO, it's worth the pain. I am currently doing it and I'll send you the list when it is ready. Awesome. Even if not used in this feature, it could potentially be

Re: [PHP-DEV] [RFC] Pipe Operator

Le 14/05/2016 à 18:35, Sara Golemon a écrit : On Sat, May 14, 2016 at 3:33 AM, François Laupretre wrote: Le 14/05/2016 à 01:36, Simon Welsh a écrit : \>> Sure, you could try to use the type of the value being passed in, but that ends up much more magic and then you run into

Re: [PHP-DEV] [RFC] Pipe Operator

On Sat, May 14, 2016 at 3:33 AM, François Laupretre wrote: > Le 14/05/2016 à 01:36, Simon Welsh a écrit : \>> Sure, you could try to use the type of the value being passed in, >> but that ends up much more magic and then you run into the same >> problem with strpos, or

Re: [PHP-DEV] [RFC] Pipe Operator

Le 14/05/2016 à 01:36, Simon Welsh a écrit : I’m not fond of this approach. Take in_array as an example. I have, in the same file, piped an array in as the second argument and piped a string in as the first. To have the position of the piped variable be implicit, you’ll need multiple versions of

Re: [PHP-DEV] [RFC] Pipe Operator

Le 13/05/2016 à 20:16, Sara Golemon a écrit : Just to verify, you're suggesting an end-state something like this? $ret = array(1,2,3) |> array_map(function($x) { return $x * 2; }) // lhs implicitly passed as second arg |> array_sum(); // implicitly passed as only arg (first position) //

Re: [PHP-DEV] [RFC] Pipe Operator

> On 14/05/2016, at 4:16 AM, Sara Golemon wrote: > > On Fri, May 13, 2016 at 10:18 AM, François Laupretre wrote: >>> So we'd have to audit all 4k+ functions in the PHP runtime (and >>> provide a mechanism for defining it on userspace functions)? >> >> That's

Re: [PHP-DEV] [RFC] Pipe Operator

On Fri, May 13, 2016 at 10:18 AM, François Laupretre wrote: >> So we'd have to audit all 4k+ functions in the PHP runtime (and >> provide a mechanism for defining it on userspace functions)? > > That's right, except that, if we only consider functions accepting more than > 1

Re: [PHP-DEV] [RFC] Pipe Operator

Hi Sara, Le 13/05/2016 à 00:41, Sara Golemon a écrit : So we'd have to audit all 4k+ functions in the PHP runtime (and provide a mechanism for defining it on userspace functions)? That's right, except that, if we only consider functions accepting more than 1 arg, we just need to check about

Re: [PHP-DEV] [RFC] Pipe Operator

On Thu, May 12, 2016 at 11:52 AM, François Laupretre wrote: > If we restrict usage to function calls, we can quite easily get rid of the $$ > by > associating to each function the position where the lhs must be inserted > when used as a 'piped function call'. > So we'd have to

Re: [PHP-DEV] [RFC] Pipe Operator

Hi Sara, Le 12/05/2016 à 19:02, Sara Golemon a écrit : On Thu, May 12, 2016 at 5:48 AM, Zeev Suraski wrote: Whether it's $$ or !# or $0 or any other random symbol doesn't really matter. Agreed. Here we have a completely optional syntactic sugar, that's not nearly as widely

Re: [PHP-DEV] [RFC] Pipe Operator

On Thu, May 12, 2016 at 5:48 AM, Zeev Suraski wrote: > Whether it's $$ or !# or $0 or any other random symbol doesn't really matter. > Agreed. > Here we have a completely optional syntactic sugar, > that's not nearly as widely useful as OOP or namespaces. > Very few things will be

Re: [PHP-DEV] [RFC] Pipe Operator

On Thu, May 12, 2016 at 5:33 AM, Quim Calpe wrote: > Is $0 being considered? It's not ideal but is used as "pattern match > reference" in preg_replace, so we have a (sort of) precedent here. Same for > $1 (first capturing subpattern). > I don't believe it's been brought up yet,

Re: [PHP-DEV] [RFC] Pipe Operator

> On 12 במאי 2016, at 15:34, Quim Calpe wrote: > >> On Thu, May 12, 2016 at 12:33 PM, Davey Shafik wrote: >> >> On Thu, May 12, 2016 at 1:19 AM, Larry Garfield >> wrote: >> On Mon, May 9, 2016, at 10:21 PM, Stanislav Malyshev

Re: [PHP-DEV] [RFC] Pipe Operator

On Thu, May 12, 2016 at 12:33 PM, Davey Shafik wrote: > On Thu, May 12, 2016 at 1:19 AM, Larry Garfield > wrote: > > > On Mon, May 9, 2016, at 10:21 PM, Stanislav Malyshev wrote: > > > Hi! > > > > > > > |> seems like a common symbol to use, but it

Re: [PHP-DEV] [RFC] Pipe Operator

Hi Larry, On Thu, May 12, 2016 at 8:19 AM, Larry Garfield wrote: > On Mon, May 9, 2016, at 10:21 PM, Stanislav Malyshev wrote: >> Hi! >> >> > |> seems like a common symbol to use, but it admittedly does look a >> >> So, usage in one semi-obscure language (F#) and one

Re: [PHP-DEV] [RFC] Pipe Operator

On Thu, May 12, 2016 at 1:19 AM, Larry Garfield wrote: > On Mon, May 9, 2016, at 10:21 PM, Stanislav Malyshev wrote: > > Hi! > > > > > |> seems like a common symbol to use, but it admittedly does look a > > > > So, usage in one semi-obscure language (F#) and one

Re: [PHP-DEV] [RFC] Pipe Operator

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

Re: [PHP-DEV] [RFC] Pipe Operator

On Mon, May 9, 2016, at 10:21 PM, Stanislav Malyshev wrote: > Hi! > > > |> seems like a common symbol to use, but it admittedly does look a > > So, usage in one semi-obscure language (F#) and one completely obscure > one (Elixir) - Clojure doesn't use |> - and one proposal for Javascript > now

Re: [PHP-DEV] [RFC] Pipe Operator

Hi! > |> seems like a common symbol to use, but it admittedly does look a So, usage in one semi-obscure language (F#) and one completely obscure one (Elixir) - Clojure doesn't use |> - and one proposal for Javascript now qualifies for "common". And that counting the fact that neither of them

Re: [PHP-DEV] [RFC] Pipe Operator

On 05/09/2016 11:41 AM, Sara Golemon wrote: On Sun, May 8, 2016 at 11:45 PM, Stanislav Malyshev wrote: Neither of these is true for |>-$$ thing - it does not have any matches in any languages I can think of. You lack imagination. Here's three to get you started:

Re: [PHP-DEV] [RFC] Pipe Operator

Hi! > You lack imagination. Here's three to get you started: > > Elixir: > http://elixir-lang.org/getting-started/enumerables-and-streams.html#the-pipe-operator > F#: https://msdn.microsoft.com/en-us/library/dd233229.aspx#Anchor_11 > Clojure: https://clojuredocs.org/clojure.core/-%3E > > And

Re: [PHP-DEV] [RFC] Pipe Operator

Hi! > Are you willing to argue that PHP should never implement features not > found commonly in other languages? Because that's where you're going > with that argument. No, I'm not and no, I'm not. But I do claim it is unobvious - though that alone would not be the reason to reject it, but I

Re: [PHP-DEV] [RFC] Pipe Operator

On Sun, May 8, 2016 at 11:45 PM, Stanislav Malyshev wrote: >> Yep, that's exactly what "->" does. It's just pointless syntactic > > No, not really. Calling method on an object is an universally accepted > phrase in many languages. > I never said it wasn't. I said it was

Re: [PHP-DEV] [RFC] Pipe Operator

On 9 May 2016 at 08:45, Stanislav Malyshev wrote: > Hi! > > > I have the feeling that if everyone involved *explicitly* prefixed their > > opinions with "I think that", this would be a better and more fruitful > > Is there any other option? > As in "better options"? I don't

Re: [PHP-DEV] [RFC] Pipe Operator

Hi! > Yep, that's exactly what "->" does. It's just pointless syntactic No, not really. Calling method on an object is an universally accepted phrase in many languages. True, not all of them use ->, and for some of them -> may have other meaning, but if you tell somebody at least vaguely

Re: [PHP-DEV] [RFC] Pipe Operator

Hi! > I have the feeling that if everyone involved *explicitly* prefixed their > opinions with "I think that", this would be a better and more fruitful Is there any other option? > discussion. *You* think the syntax completely unobvious - that doesn't > make it so. Clearly others find it much

Re: [PHP-DEV] [RFC] Pipe Operator

On Sun, May 8, 2016 at 10:37 PM, Stanislav Malyshev wrote: > I don't see how it helps anything. It just replaces clear variable names > with cryptic sequences of characters with no intuitive meaning and magic > semantics invented solely to save a few keystrokes. > Yep, that's

Re: [PHP-DEV] [RFC] Pipe Operator

On 9 May 2016 at 07:37, Stanislav Malyshev wrote: > Hi! > > > "|>" is just a building block for simpler coding. It could be used > badly, but > > it helps a lot. Procedural code could be much simpler and readable with > "|>". > > I don't see how it helps anything. It just

Re: [PHP-DEV] [RFC] Pipe Operator

Hi! > "|>" is just a building block for simpler coding. It could be used badly, but > it helps a lot. Procedural code could be much simpler and readable with "|>". I don't see how it helps anything. It just replaces clear variable names with cryptic sequences of characters with no intuitive

Re: [PHP-DEV] [RFC] Pipe Operator

Hi, I agree they are bad APIs. Framework/library developer should provide better API On Mon, May 9, 2016 at 1:08 AM, Fleshgrinder wrote: > $request = getGlobals() > |> parseRequest($$) > |> buildPsr7Request($$); should be require('some.lib'); $request =

Re: [PHP-DEV] [RFC] Pipe Operator

On 5/3/2016 11:23 PM, Ryan Pallas wrote: > Waiting for what example? There's been plenty of examples showing how > existing options, rewritten with |> are easier. If you disagree, that's an > opinion, other's agree. If people think its better, why not add it for > them? Like every other feature

Re: [PHP-DEV] [RFC] Pipe Operator

On Sun, May 1, 2016 at 4:05 AM, Larry Garfield wrote: > > In a way... Sara, this syntax feels like it's only one step removed from > promises; if any of the chained steps involve IO, it becomes basically what > promises are for. Am I barking down the wrong tree, or is

Re: [PHP-DEV] [RFC] Pipe Operator

On Tue, May 3, 2016 at 12:53 PM, Terry Cullen wrote: > ​Doesn't Nikic's scalar objects (https://github.com/nikic/scalar_objects) > more or less achieve the same thing while also cleaning up the std lib? > > $ret = scandir($arg) > ->filter(function(){}) >

Re: [PHP-DEV] [RFC] Pipe Operator

Hi Sara, On Sat, Apr 30, 2016 at 4:58 AM, Sara Golemon wrote: > This is one of my favorites out of HackLang. It's pure syntactic > sugar, but it goes a long way towards improving readability. > https://wiki.php.net/rfc/pipe-operator PHP is not pure OO anyway. This proposal

Re: [PHP-DEV] [RFC] Pipe Operator

On Tue, May 3, 2016 at 2:35 PM, Fleshgrinder wrote: > On 5/3/2016 10:22 PM, Ryan Pallas wrote: > > I have to disagree, I haven't seen an example of rewriting the original > > example from the RFC in a more expressive AND readable way. Yes, you can > > use lots of

Re: [PHP-DEV] [RFC] Pipe Operator

On 5/3/2016 10:22 PM, Ryan Pallas wrote: > I have to disagree, I haven't seen an example of rewriting the original > example from the RFC in a more expressive AND readable way. Yes, you can > use lots of intermediate variables, but this makes the code HARDER to read > QUICKLY which is entirely the

Re: [PHP-DEV] [RFC] Pipe Operator

On Tue, May 3, 2016 at 1:28 PM, Fleshgrinder wrote: > On 5/3/2016 8:57 PM, Sara Golemon wrote: > > Ooops, missed a negation when I typed it out. > > > > "Pretending that poorly designed libraries DON'T exist is naîve." > > > > I am not pretending that they do not exist,

Re: [PHP-DEV] [RFC] Pipe Operator

On 5/3/2016 8:57 PM, Sara Golemon wrote: > Ooops, missed a negation when I typed it out. > > "Pretending that poorly designed libraries DON'T exist is naîve." > I am not pretending that they do not exist, quite the contrary, I explicitly stated that they exist and that I fear that this

Re: [PHP-DEV] [RFC] Pipe Operator

On 03/05/16 19:57, Sara Golemon wrote: > Intermediate variables also add cognitive overhead of their own in > cataloging all the various intermediates used in a large function. By > removing the explicit intermediate variables and replacing them with > unnamed temporaries, the code becomes easier

Re: [PHP-DEV] [RFC] Pipe Operator

On Tue, May 3, 2016 at 11:52 AM, Fleshgrinder wrote: > On 5/3/2016 8:45 PM, Sara Golemon wrote: >> Pretending that poorly designed libraries exist is naîve. >> > I really do not know what you want to tell me with that first sentence. > Ooops, missed a negation when I typed

Re: [PHP-DEV] [RFC] Pipe Operator

On 5/3/2016 8:45 PM, Sara Golemon wrote: >> The pipe operator is also just a work around for poorly designed >> libraries in this case and yields more poorly designed libraries. >> > Pretending that poorly designed libraries exist is naîve. PHP is > dominated by poorly designed software but it

Re: [PHP-DEV] [RFC] Pipe Operator

On Tue, May 3, 2016 at 11:36 AM, Fleshgrinder wrote: > On 5/3/2016 8:12 PM, Sara Golemon wrote: >> The difference with scalar objects is: >> A) We need to agree on what methods these objects are going to have. >> ((And we won't agree)) >> > > The nice thing here is that we

Re: [PHP-DEV] [RFC] Pipe Operator

On 5/3/2016 8:12 PM, Sara Golemon wrote: > The difference with scalar objects is: > A) We need to agree on what methods these objects are going to have. > ((And we won't agree)) > The nice thing here is that we could start with the things that we agree on and develop it from there further. On

Re: [PHP-DEV] [RFC] Pipe Operator

On Tue, May 3, 2016 at 11:29 AM, Lester Caine wrote: > Which does beg the question ... "Just how many problem spaces are > currently under discussion?" ... There is a space for some additional > extensions that provided experimental solutions to some of the perceived >

Re: [PHP-DEV] [RFC] Pipe Operator

On 03/05/16 19:12, Sara Golemon wrote: > I like the scalar objects approach as well. Heck, I wrote one three > years ago: https://github.com/sgolemon/objectifier but I don't think > it solves the same problem space as pipe chaining. Which does beg the question ... "Just how many problem spaces

Re: [PHP-DEV] [RFC] Pipe Operator

On Tue, May 3, 2016 at 9:30 AM, Fleshgrinder wrote: > On 5/3/2016 4:53 AM, Terry Cullen wrote: >> Doesn't Nikic's scalar objects (https://github.com/nikic/scalar_objects) >> more or less achieve the same thing while also cleaning up the std lib? >> >> $ret = scandir($arg)

Re: [PHP-DEV] [RFC] Pipe Operator

On 5/3/2016 4:53 AM, Terry Cullen wrote: > ​Doesn't Nikic's scalar objects (https://github.com/nikic/scalar_objects) > more or less achieve the same thing while also cleaning up the std lib? > > $ret = scandir($arg) > ->filter(function(){}) > ->map(function(){}) >

Re: [PHP-DEV] [RFC] Pipe Operator

Stephen Coakley wrote on 03/05/2016 01:57: On 04/30/2016 06:14 PM, Rowan Collins wrote: The basic pattern would be: |=> $tempVar; // terminate the chain and capture the value // do stuff with $tempVar $tempVar // restart the chain So: scandir($arg) |> array_filter($$, function($x) {

Re: [PHP-DEV] [RFC] Pipe Operator

I am very much in favour of this. I would typically write the example with an intermediate variable to avoid all the sad nesting. $files = scandir($arg); $files = array_filter($files, function ($x) { return $x !== '.' && $x !== '..'; }); $files = array_map(function ($x) use ($arg) { return $arg .

Re: [PHP-DEV] [RFC] Pipe Operator

Am 30.04.2016 um 01:37 schrieb Bob Weinand: > TL;DR: > -1: The |> pipe operator encourages a write-only style. I second that emotion. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Pipe Operator

On 03/05/16 05:49, Sara Golemon wrote: > It's way more readable in the pipe syntax version, but it's > overloading a single statement in both places. The rop examples show another style of working BUT it only really changes the way of ordering SOME elements of the code. And the pipe operator is

Re: [PHP-DEV] [RFC] Pipe Operator

On Mon, May 2, 2016 at 5:57 PM, Stephen Coakley wrote: > Could you use a closure instead to accomplish this? (Again yes, Sara could > you clarify if this is permitted?) > > $ret = scandir($arg) > |> array_filter($$, function($x) { return $x !== '.' && $x != '..';

Re: [PHP-DEV] [RFC] Pipe Operator

On 3 May 2016 at 10:57, Stephen Coakley wrote: > On 04/30/2016 06:14 PM, Rowan Collins wrote: > >> On 29/04/2016 20:58, Sara Golemon wrote: >> Let's say I want to add a condition just before getFileArg(); with the >> current version I've got to: >> - go to the beginning

Re: [PHP-DEV] [RFC] Pipe Operator

On 04/30/2016 06:14 PM, Rowan Collins wrote: On 29/04/2016 20:58, Sara Golemon wrote: Let's say I want to add a condition just before getFileArg(); with the current version I've got to: - go to the beginning of the chain, and assign to something other than $ret - go to where I want to break the

Re: [PHP-DEV] [RFC] Pipe Operator

On 04/30/2016 01:05 PM, Larry Garfield wrote: On 04/29/2016 07:19 PM, Stanislav Malyshev wrote: In a way... Sara, this syntax feels like it's only one step removed from promises; if any of the chained steps involve IO, it becomes basically what promises are for. Am I barking down the wrong

Re: [PHP-DEV] [RFC] Pipe Operator

On Mon, May 2, 2016 at 12:56 AM, Michael Wallner wrote: > On 30/04/16 20:57, Sara Golemon wrote: >> What follows is a terrible idea and I don't mean to propose it as a >> solution, but to spark further conversation: >> >> $result = getData() >> ?> doStuffWith($$) > > I thought

Re: [PHP-DEV] [RFC] Pipe Operator

On 30/04/16 20:57, Sara Golemon wrote: > On Sat, Apr 30, 2016 at 11:41 AM, wrote: >> God I hate crap software ... TRYING to reply without top post ... but >> Samsung is incapable! >> >> What I was trying to comment on was that trapping that no result is returned >> may be

Re: [PHP-DEV] [RFC] Pipe Operator

Le dimanche 1 mai 2016, 00:20:45 Dan Ackroyd a écrit : > However, it is not the proposed new syntax that makes the code more > readable - it is solely due to writing it in the correct order that > makes the code more readable. This can be done using current PHP > syntax, so that the code is: > >

Re: [PHP-DEV] [RFC] Pipe Operator

On 01/05/16 15:39, Dan Ackroyd wrote: > Marco wrote: >> > Relevant: https://youtu.be/UvD1VjRvGIk > I could imagine how having inline branches could be a useful thing for > functional programming, for various scenarios, including being able to > 'inline' error handling, to be nearer the source of

Re: [PHP-DEV] [RFC] Pipe Operator

On 30 April 2016 at 07:49, Marco Pivetta wrote: > Here's the pseudo-code for a typical request/response dispatch cycle: Hi Marco, Could you clarify something for me? If I submitted a pull-request to you, with variables named like this: $v = buildRequest(); $v =

  1   2   >