reorganise JCodemodel class with internal fields/methods

[glelouet]

The idea is to have everything needed for using a code model inside it.

Typically a code creation involves creation of the classes, generation of the expressions, and then writing somewhere.

I propose for each X in [create, link, exp, write] to have an internal class (non static) JCMX (eg JCMcreate) that proposes all the functions linked to this activity (here, creation of internal classes/resources/packages). The JCM would then have a final field (I would like public final but I guess it will be nope) X (so create) as well as a method (so create() )that returns that field.

eg :

JCodeModel{
[…]
  public class JCMCreate{
    // here we move the code from JCM
    _class(…){}
  }
  public final JCMCreate create = new JCMCreate();
  public JCMCreate create() {return create;}
  //replace previous moved code with 
  _class(…){return create._class(…);}
}

The same with write, except write() will delegate all the calls. Typically write.toFile(File file) will create a new JCMWriter and call build on it with the file in parameter.

WHY ? Because when I use JCM I often spend time to find out how a thing is done. Typically, JExpr allows to make expressions, but if I want use wildcard or a ref to String, I still need to use JCM.

So I propose the following split :

• create is for creation, listing, etc. of resource, class, package - that is, anything that should produce a resource.
• link allows to link existing entities. So all the lit() methods, all the_ref(Class) methods.
• exp allows to create expressions in the JCM. the wildcard should go there, as well as most (all? except null that should go in link)
• write contains the calls to export the JCM into something else. For example the toMemory() {return MemoryCodeWriter.from(this.JCodeModel).compite();}

Then several methods that are present in the JCM should be deprecated (with reason : use #link.#_ref() or use #create.#_class()) and scheduled for removal on future major version.

[glelouet]

first step is to make the write field. It's the simplest one and won't require much time.

Also I forgot to say, but those subclasses are stateless. All the state is still in the JCM. They can be marked as transient.

[glelouet]

been working on a POC :
master...guiguilechat:#93

Ignore changes before line 1090

I switched to a private field instead of public final so that they could be changed to have a strategy pattern. Actually they could still be final public, and assigned in the constructor. but with the var keyword it's easy to do something like

JCodeModel cm = new JCodeModel();
var ref = cm.ref(), expr=cm.expr(), […]

[glelouet]

As you can see, this is just syntax sugar, with the goal to be the more easily usable for a dev.

Another option would be, to make another class (say JCodeSugar) that contains the code I wrote AND a JCodeModel. I think this option is the best because it won't impact versioning( you just add a new class)

[glelouet]

pushed a commit on my branch to move the differences in a specific package (sugar)