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 smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
