Method chaining JEP draft

[JARvis PROgrammer]

Got it, thanks a lot Remi and Brian for your detailed feedback to this
topic.

вс, 31 мар. 2019 г. в 18:33, Brian Goetz <brian.goetz at oracle.com>:

> You are correct, this request has come up quite a few times over the
> years, including in Project Coin, and there is nothing intrinsically
> unsound about this feature.  (Though, it's not all roses and sunshine
> either -- it does blur the definition of what "void method" means, among
> other issues.  So there are definitely "pros and cons", as you say.)
>
> But, underlying your question is an assumption: that the bar for adding
> a feature is "it's a good idea."  Surely we don't want to add bad ideas,
> but the bar is much higher than that.  The main reason we've not done
> this is not that we think its terrible (its OK, not great, not
> terrible), nor that it never occurred to us (trust me, this is never the
> reason); it's that there are other, better features we could be spending
> our limited { analysis, implementation, specification, complexity,
> novelty, education } budgets on.  It just doesn't seem to be very close
> to the top of the list.
>
> (For the record, what I like best about this feature is that it allows
> us to make more computations into expressions; this is good because
> expressions compose better than statements.)
>
> Now, I hear you thinking: "but it's such a simple feature, surely we can
> just sneak it in?"  Which is an attractive thought, but in reality,
> nothing is a simple feature -- and once we have this feature, it may
> constrain the development of future features.  So, it's on the "list",
> and it might come to the top eventually, but right now, other features
> (records, sealed types, pattern matching, value types, specialized
> generics) seem like better investments.
>
> > Hi there,
> > At current I am working on a draft for the language feature to allow
> > non-static methods to declare themselves as `returning instance on which
> > they were called` (a builder pattern is the best illustration of such
> type
> > of methods) making it automatic (rather than forcing the developer to
> > use return
> > this) or (as another option to be declared by this JEP) to allow such
> > behaviour for void methods.
> > This is a draft at my local PC (he-he) and Gist at the moment and is only
> > under construction but is it at all worth workin on it? This feature
> seems
> > to be an obvious one and might have been discussed in past and yet there
> > seems to be no JEP addressed for it.
> >
> > So should I continue working on a draft (for discussion here, of course)
> or
> > this was already discussed and there are already existing pros&cons for
> > this because of which this feature is not anywhere now?
> >
> > Thanks,
> > Peter P.
>
>