JShell.setIdGenerator/setTempVariableNameGenerator

[Robert Field]

I'm really concerned that the audience for this is getting lost. Design 
rules appropriate for java.lang or java.util and newbie programmes, don't 
apply to an API designed for a handful of IDE developers and homegrown tool 
hackers. A real tool is likely to need Builder functionality, hiding it too 
deeply doesn't serve either. And you can't/don't want to hide the Builder 
-- how would the builder() factory be documented?

-Robert



On July 23, 2015 10:11:35 AM Paul Sandoz <paul.sandoz at oracle.com> wrote:

>
> On 23 Jul 2015, at 18:38, Brian Goetz <brian.goetz at Oracle.COM> wrote:
>
> >> I don't want two different ways to create an instance -- that adds 
> unneeded complexity.  I don't want to blend the builder functionality into 
> the dynamic functionality, that defeats the goal of separating out the 
> functionality that is obscure, set-up related, and one-time from that that 
> is state-bound and dynamic.
> >>
> >> This is a tool API. The number of people who will have to type "new 
> JShell.Builder().build()" in small.
> >
> > I understand the argument, but the “express" version often does carry its 
> weight.  The issue here is _discoverability_.  For the folks who just want 
> an instance, they don’t have to learn about the builder and figure out when 
> builder features they want; they can just invoke the simple static factory. 
> (Having a static factory method whose spec just says “this is equivalent 
> to…” doesn’t add a lot of complexity.)  Builders are great but they are 
> often an extra concept that has to be navigated before you can do anything 
> useful.
> >
>
> Yes, that’s often my experience when designing and using ‘em.
>
>
> > (I also prefer a static factory for the builder; JShell.builder(), which 
> can be a sibling to JShell.newInstance(), and that way the user doesn’t 
> have to even utter the name of the builder abstraction.)
> >
>
> +1.
>
> Paul.