FWIW, I've read the manual page for the Hack page, and the RFC, a couple of times now, and I simply don't understand it.
Are most PHP developers going to understand this feature, the meaning of $$, and when/how to use this? Are they going to be able to read code written in this way? To your knowledge, are there any other languages where this feature is found, or is it another one of those exotic features currently found in Hack and nowhere else? (I know a bunch of languages, and this feature doesn't ring any bells.) How does this feature compare with the cascade operator more commonly found in other languages? I mean, maybe it's just me, because I'm familiar with the cascade operator from other languages - but it seems simpler, more intuitive, easier to pick up, and appears to solve most of the same problems? If so, perhaps it would be right to consider the cascade operator as an alternative to this feature. I know that Hack may be closer in nature to PHP than some other languages, but if someone is familiar with both, likely they're not coming from Hack and moving to PHP, they're likely moving from PHP to Hack, so language similarity might not be the best argument for referencing Hack on this point, as opposed to referencing other languages... It seems to me, the main difference between the pipe operator and a cascade operator, is the anonymous context variable $$ created by the pipe operator - I think, partially, this is what makes those expression hard to read; the context changes (or does it?) along the way, but the (nameless) symbol used to reference those objects, in the same expression, are identical. Rather than writing extremely long expressions, as demonstrated in the RFC, I think, personally, if this feature were introduced, I'd lean more on intermediary variables, with names, that clarify the meaning - referencing a bunch of intermediaries with a nameless variable doesn't help readability at all, in my opinion. In contrast, I have no issue reading expressions with the cascade operator; again, maybe that's just because I'm familiar with that operator from other languages, but I don't think the nameless $$ variable helps readability or understanding. Just my two cents. On Fri, Jul 22, 2016 at 5:54 PM, Larry Garfield <la...@garfieldtech.com> wrote: > On Wed, Jul 20, 2016, at 11:37 PM, Sara Golemon wrote: > > > > However, the introduction discusses fluent chained methods of objects, > and > > > states " This RFC aims to improve code readability by bringing fluent > > > expressions to functional and OOP libraries not originally designed > for the > > > task." The examples, however, all seem to be centered around > procedural > > > calls. (A static method call is the same thing as a procedural > function > > > call in this respect.) When dealing with methods on an object, it > seems it > > > wouldn't offer much. > > > > > In this context, I'd argue instance method calls aren't much different > > from static method calls either, but I wanted to avoid too many > > abstract/contrived examples. > > > > I suppose one might do something like: > > > > return $this->loadConfig() > > |> $arg->useConfig($$) > > |> $this->loadUser($$) > > |> array_merge($$, $this->userDefaults); > > > > But the PSR7 example is already contrived as it is. > > > > > This other recent discussion/proposal for a "Cascade" operator seems > like it > > > would handle the OOP/method case much better: > > > > > > http://news.php.net/php.internals/94466 > > > > > > Note: I am not suggesting one is a substitute for the other; rather, > that > > > they are complementary by addressing different parts of the problem > space, > > > and the Pipe RFC should likely not emphasize OOP usage potential as I > see > > > not a great deal there. I am still in favor of it, but let's not > over-state > > > its use cases. > > > > > Fair enough. They certainly complement one another and I wouldn't > > argue either is a one-job-fits-all solution. I wasn't trying to > > emphasize OOP usage so much as include it as applicable. I think we > > might actually be agreeing in principle even if we're diverging in our > > word choices. :) > > I agree. I'm entirely on board with the feature; more just critiquing > the RFC intro text, which mentions OOP fluency as a use case, which I > think is an over-reach. It's a useful enough feature even without > talking about that, and it seems we agree that the syntax when used with > methods is a bit awkward. > > > P.S. - I'm totes going to make that a secondary voting choice now. > > Name the token, 50% majority wins. > > :-) > > --Larry Garfield > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
