Repository navigation
Structs: Infer parameter members from functional method signature instead from solely annotations #2
Description
Currently, ParameterStructs utility class only check for @Parameter annotations in order to structify an object. Instead, members should be inferred from the signature of the functional method of the class of the passed object. This should have the following behavior:
- If no
@Parameterannotations are given, the type and theItemIOshould be inferred from the functional method signature. In doing so, the return type will always beItemIO.Outputand method parameters should beItemIO.Input. If a method parameter isItemIO.Both, it should be annotated with a@Mutableannotation. Methods to get the functional method types from a type and the@Mutablealready exists. - Additionally, the
@Parameterannotations may be given in order to specify the names and further metadata of the member (e.g. required status). Also, this enabled to do fail fast checks if theItemIOor the number of parameters does not match the types inferred from the functional method. - A
ItemIO.Autowas already added in order to indicate that theItemIOshould be automatically inferred from the functional method.ItemIO.Autoshould be made the default.
Activity
ctrueden commentedon May 15, 2019
@MarcelWiedenmann Can you please check whether this work was ever completed? And if not, try your hand at it? Thank you!
Treiblesschorle commentedon May 16, 2019
There is an open PR which is done. However, a lot seems to have changed in the meantime, hence I'm not sure if this can be easily merged.
ctrueden commentedon May 16, 2019
Thanks @Treiblesschorle. For reference the PR is #11. And ouch, I had forgotten all about that, and now the histories are probably very incompatible. Sorting out the patches will take some time.
Treiblesschorle commentedon May 16, 2019
@MarcelWiedenmann we can have a look at it together if you want.
wiedenm commentedon May 21, 2019
@ctrueden As previously discussed in person, rebasing #11 onto the most recent
new-opsbranch was straightforward. I still had a look at the PR, mainly because @Treiblesschorle was a bit concerned about the new dependency to io.leangen.geantyref that is added by the PR. We use GeAnTyRef to synthesize Parameter annotations. For what it's worth, I tried to copy over GeAnTyRef's relevant internal functionality and it's about 250 LoC we use. The entire project has ~4300 LoC. Don't know if that matters or if using that dependency is just fine.Other than that, the PR looks good to me. I rebased it onto
migrate-imagej-opson my machine to see if those tests still run through, and they do.ctrueden commentedon May 21, 2019
Would GeAnTyRef be able to replace all the generics-related features of
org.scijava.util.Types? I.e.: could we get rid of the Apache CommonsTypeUtilsfork and the GenTyRef fork, and get rid of the Guava dependency, and makeNiluse GeAnTyRef'sTypeTokeninstead?Anyway, I'm fine merging as-is for the moment. But the proliferation of generics-related code, much of it overlapping, bugs me. I'd much rather have one clean upstream generics reasoning dependency, if it can meet all our needs.
wiedenm commentedon May 21, 2019
That would be nice. I'll create a dedicated issue for that & do some exploration.
+ Merging for now sounds good 👍.
ctrueden commentedon Sep 22, 2019
Resolved by 623d0cd.