11 lip 2016 18:31 "Rasmus Schultz" <ras...@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
>
> 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
>
