On Mon, Jul 11, 2016 at 1:55 PM, Michał Brzuchalski <
michal.brzuchal...@gmail.com> wrote:
> 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
>
>
>
Agreed, but what about static methods? Triple colon perhaps?
A::setFoo(1)
:::setBar(2)
:::setBaz(3);
And I do agree that the double period is cleaner, but the bus left the
station a very long time ago (PHP 3 at least) by making . the connotation
operator. Or at least I think so. If the parser could deal with it double
period would be best because it could apply to both contexts.
$object->setFoo(1)
..setBar(2)
..setBaz(3);
A_Class::setFoo(1)
..setBar(2)
..setBaz(3);
But again, I don't know how feasible the above is since I know next to
nothing about internals.
