Cascade Operator (was Re: Proposal for php7 class method return)

11 lip 2016 18:31 "Rasmus Schultz" rasmus@mindplay.dk napisał(a):

what's the actual added value of this sort of operator?

The only direct value to the language is brevity - mere convenience.

But I think the biggest indirectly added value, is that this will
discourage people from the chainable methods anti-pattern - so this
has value to the community; those who write chainable methods can
stop, and those who want chainable methods can get a wider choice of
libraries that were previously too verbose in use for their taste.

For this sort of chaining I'd propose, in addition to the cascade
operator,
the chain operator. This would work like the cascade operator except
that
the return of the function is implicitly the first parameter of the next
argument in the chain

I don't like this idea, at all - I think we should aim for something
consistent with other languages. Per the Dart spec:

A cascaded method invocation expression of the form e..suffix is
equivalent to the expression (t){t.suffix; return t;}(e).

In other words, the expression always evaluates as the object, which
is fine for most cases, e.g. for everything you're doing with
chainable methods today - which can't actually return any values,
since they return $this. Note that something like PSR-7's HTTP
immutable models are actually factory methods, e.g. use-cases not
applicable to the cascade operator.

The other marginal use case perhaps is cases where a builder of some
sort ends with a call to a factory method - this can be done without
adding a second operator, by using parens in a similar fashion to Dart
and others, e.g.:

$object = ($builder
    ->>setFoo(1)
    ->>setBar(2)
    ->>setBaz(3)
)->build();

Or obviously:

$builder
    ->>setFoo(1)
    ->>setBar(2)
    ->>setBaz(3);

$object = $builder->build();

Regarding syntax - I feel the natural choice, e.g. similar to "." vs
"..", would be a longer arrow --> but that's ambiguous. (decrement
operator, greater than operator)

The proposed |> operator looks horrible and is very awkward to type,
at least on both American and Danish keyboard - I use both. (it reads
like "or greater than" in my mind, so much so that glancing over
Sara's proposal earlier, I didn't even understand what it was.)

Would something like ->> be ambiguous as well? That's fairly close too

• a double-headed arrow, not unlike the double dots of other
  languages...

IMHO double-headed arrow looks pretty nice and whole idea is great. Very
big +1 for this feature

Still interested: what's the actual added value of this sort of
operator?

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

But for that to currently work setSomething must return $this. A
cascade
operator would avoid this. What about => ?

$a->setSomething('here')=>setSomethingElse('there');

This will be ambiguous with array syntax, e.g.

$foo = [ $a->foo() => bar() ]

could be a call to $a->foo() for the key and to bar() for the value, or
just a chain ending with the array value $a->bar().

Naming things is hard. Inventing operators is harder. ;)

Also note that it's the first call that needs a special operator, in
order to discard the normal return and substitute the left-hand side,
otherwise mixed chains become ambiguous and probably horrible to
implement
in the engine:

$foo->bar()->baz()=>bob() // what is $this inside bob() ?

For this sort of chaining I'd propose, in addition to the cascade
operator,

the chain operator. This would work like the cascade operator except
that
the return of the function is implicitly the first parameter of the
next
argument in the chain. Something like this?

$a->add(1, 2):>subtract(3):>add(4); // return 4.

This exact feature was proposed a couple of months ago by Sara Golemon.
See https://wiki.php.net/rfc/pipe-operator and the accompanying
discussion http://marc.info/?t=146196088900001&r=4&w=2

As far as I know, it's not been formally withdrawn, so might be
resurrected in some for for 7.2. It might be interesting to see a
cascade
operator at the same time, but some of the same concerns that came up
in
that discussion will probably apply to any proposal.

Regards,

Rowan Collins
[IMSoP]

2016-07-11 13:30 GMT-03:00 Rasmus Schultz rasmus@mindplay.dk:

Regarding syntax - I feel the natural choice, e.g. similar to "." vs
"..", would be a longer arrow --> but that's ambiguous. (decrement
operator, greater than operator)

Yes, it's ambiguous. It will also get confused for the (in)famous "goes to
operator":
http://stackoverflow.com/questions/1642028/what-is-the-name-of-the-operator

what's the actual added value of this sort of operator?
The only direct value to the language is brevity - mere convenience.

But I think the biggest indirectly added value, is that this will
discourage people from the chainable methods anti-pattern - so this
has value to the community; those who write chainable methods can
stop, and those who want chainable methods can get a wider choice of
libraries that were previously too verbose in use for their taste.

As one of those proponents of chained methods / returning $this, I quite
like this proposal. It neatly handles many (although not all) of the
use cases for method chaining, specifically the most controversial ones,
while not having any of the same potential issues. (Eg, when composing
and delegating the method call to another object, you have to do some
$this juggling.) It would not remove the need for all method chaining,
but it would remove the need for the controversial ones that Rasmus is
complaining about while letting people like me still write nicely
compact and readable code. :-)

(Modulo implementation details and debating the operator symbol for a
few weeks, as per usual.)

--Larry Garfield

Would something like ->> be ambiguous as well? That's fairly close too

• a double-headed arrow, not unlike the double dots of other
  languages...

A few weeks ago I proposed a syntax for setting multiple object properties
in an expression with the result as the object (
http://news.php.net/php.internals/93662). Both that feature and the cascade
operator can be considered instances of a broader need to manipulate an
object as an expression with the result being the object itself, and either
feature could support both calling a method and setting a property:

$this->setBlah(
Blah::create(4)
->>foo = $foo
->>baz = ((new Baz())
->>markFixed()
->>label = "Hello"
)
->>setBot(9)
);

$this->setBlah(
Blah::create(4) {
foo = $foo,
baz = new Baz() {
markFixed(),
label = "Hello",
},
setBot(9),
}
);

Would it be incohesive to have two different syntaxes for setting
properties and calling methods, like below?

$this->setBlah(
Blah::create(4) {
foo = $foo,
baz = (new Baz())
->>markFixed()
{ label = "Hello" },
}
->>setBot(9)
);

If so, some consideration should be made as to which syntax is preferred to
solve this problem generally for both setting properties and calling
methods.

I prefer the "obj { .. }" syntax because it mirrors object literals in
JSON/JavaScript, object initializers in C# and C/C++ and Haskell record
syntax, is particularly concise when nested to create large trees of
objects, and avoids the noise of "->>" on each line.