Configuration of the processor

[gneuvill]

That could be useful to enforce the use of a single representation of HKTs (i.e one of the three described here https://github.com/derive4j/hkt/issues/1#issuecomment-204116116) through a project

[jbgi]

Right, in fact I think the uniformity could be enforced without configuration, by taking the first encoding found as the norm for all subsequent classes to be processed. But the uniformity would still be local to the compilation unit, so configuration (how?) could still be useful.

[gneuvill]

But the uniformity would still be local to the compilation unit

How's that ? I don't understand.

[gneuvill]

so configuration (how?)

I was thinking of an interface an implementation of which we would search after as the first step of the type checking (error if more than one impl...?).

[jbgi]

How's that ? I don't understand.

I mean: users may want to enforce uniformity across multiple projects.

[gneuvill]

users may want to enforce uniformity across multiple projects

Ah ok. Well, following my idea, that would be one configuration class per project.

[gneuvill]

I was thinking of an interface an implementation of which we would search after as the first step of the type checking

Silly idea of mine... We obviously don't have any implementation at our disposal in the processor since we're compiling them (less we turn the processor into a macro system, let's not try that)

So, I guess the configuration system shall rely on annotations once again (after all, it is an annotation processor we're writing). The problem is that annotations must be put on something :

• is it possible to annotate package declaration in package-info files ?
• alternatively, would it be acceptable to mandate the user to create a dummy class to annotate if he wants global configuration ?

[jbgi]

Replication a comment that was in the wrong issue:

I think the hkt processor should generate one Narrow class per package, and an annotation in the package-info class could be used for configuration: name of class, template of narrow method, visibility of the Narrow class. WDYT?

edit: so yes we can annotate package declaration in package-info files

[jbgi]

Also the package annotation could be use by both derive4j and hkt: a boolean in the annotation could decide which processor is responsible to generate narrow method for @Data annotated classes.

Also the annotation could be "inherited"/overridable: we can lookup-up the hierarchy, up to the root package, for the configuration annotation, so that we are not forced to add the annotation on each package.

[gneuvill]

So you're thinking about a hierarchical model where each sub-configuration would override the parent one, am I right ? That's what I was conceiving on my side... provided we can indeed annotate a package declaration in a package-info file ! Is this possible ?

[jbgi]

yes, exactly. package-info are annotable no prb.

[jbgi]

@gneuvill I was thinking that maybe for a first version, the configuration annotation might be overkill. What do you think about just generating the methods in a package private HKT class? I got the feeling that public HKT class should not be used, otherwise there will be a proliferation of public HKT classes in the classpath. edit: this comment was intended for the generation part: #16/#8. @gneuvill Are you going to work on that one also short term? otherwise I might give it a go.