-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Configuration of the processor #11
Comments
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. |
How's that ? I don't understand. |
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...?). |
I mean: users may want to enforce uniformity across multiple projects. |
Ah ok. Well, following my idea, that would be one configuration class per project. |
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 :
|
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. edit: so yes we can annotate package declaration in package-info files |
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 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. |
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 |
yes, exactly. package-info are annotable no prb. |
@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. |
That could be useful to enforce the use of a single representation of HKTs (i.e one of the three described here #1 (comment)) through a project
The text was updated successfully, but these errors were encountered: