> 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...
On Mon, Jul 11, 2016 at 5:33 PM, Marco Pivetta <ocram...@gmail.com> wrote:
> Still interested: what's the actual added value of this sort of operator?
>
> Marco Pivetta
>
> http://twitter.com/Ocramius
>
> http://ocramius.github.com/
>
> On 11 July 2016 at 17:28, Rowan Collins <rowan.coll...@gmail.com> wrote:
>
>> On 11/07/2016 16:15, Michael Morris wrote:
>>
>>> 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]
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
