-
Notifications
You must be signed in to change notification settings - Fork 125
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
[Question] [Extensions] Use existing (non-annotated) classes as extension #597
Comments
This is possible with manifold, however it is not so readily possible. You can generate extension classes based on other resources and classes. See Generating extension classes.
This is basically saying you can write a type manifold that generates extension classes for just about any scenario, including the one you're proposing. But I'm thinking this should be a more directly supported feature. Something like this: package myproject.extensions.java.nio.file.Paths;
@Extension(source=java.nio.file.Files.class)
public class MyPathsExt {
} Here we support the feature with an optional Nice example too, the Paths, Files, etc. nio stuff is confusing. Great suggestion! |
This seems a bit more complex than the proposed solution. However, I'm going to try to make this work. Nice to see that so much is possible! Thanks for pointing out how to do it. |
It reflects the difference in extension architecture between manifold and Lombok. With manifold extensions apply to modules and “just work”, with Lombok extensions must be manually included in each file that uses them. There are pros and cons to both techniques. In my experience I almost always want them to “just work” particularly in the IDE. Having to include them manually is a PITA when nearly 100% of the time the extension is intended to be accessible across the entire module. Again, this relates to my own experience and preferences. Of course, these techniques are not mutually exclusive, so I understand your proposition is meant to combine them. My proposal is just meant to augment the existing architecture with the means to also support static libraries as extension classes. After that is finished a discussion can be had about scoping extensions at the file level similar to Lombok, C#, etc. |
I won't stop you ;) But as you probably know I am rather particular about pull requests, they are heavily scrutinized and unless they fit like a glove I tend not to accept them as PRs. Not because they aren't well crafted, but primarily because I didn't write them. While that may sound off putting, it comes down to the time required to thoroughly digest the code, the collaboration, the testing, the perf, the IDE plugin impact, the future maintenance burden, etc. By the time I've finished all of that, I may as well have written it myself, probably in less time. Normally, I wouldn't take such a guarded stance with a project. But most projects are far easier to grok and maintain. Manifold is insane on many levels, but it has to be. Anyhow, I appreciate your attention and contributions to this project. Your feedback is priceless! I don't want to discourage you, I want you to keep it coming, including going forward with this proposal. I'm just setting expectations. Hopefully, you're still on board :) |
No problem at all. I didn't intend to create a PR just yet, but I enjoy diving deeper into the code. I'm just scratching the surface and currently have only a very basic overview of it. |
@rsmckinney After further testing, I can conclude that it is working. Compilation is successful. However, IntelliJ cannot resolve the methods, nor is there any content assist. My guess is that the source files in the target folder are not being picked up by the Manifold-IJ plugin, even though the target folder containing the generated source file is marked as a source folder. |
Hey @EotT123 sorry for not getting back sooner, been busy with other stuff, coming up for air now... We can talk about why the files aren't picked up, however my preferred way of achieving this feature would not involve creating a conventional annotation processor and generating intermediate source files. Instead, why not just process |
I'd need to examine your code to figure out what's happening/not happening. Perhaps a simpler solution is to just follow extension producer sample more closely. Just create a resource file type, say with a
Pretty straightforward if you follow along with that sample project and its test module. I think I like this approach most. |
I managed to make it work, there was a very small bug in my code, and it took me a long time to figure it out (many hours debugging the code, going through all the Manifold code that handles most of the processing). @ExtensionClass(Files.class) // creates extension methods of all methods defined in Files.class
@Extension
public class PathExtension {
// other extension methods
} I created a separate annotation because I wanted to use it as an add-on to the Manifold framework without modifying the Manifold code. |
Nice! |
Created a PR which implements this functionality: #653 |
Created a new PR with new implementation: #662 |
Like Manifold, Lombok also supports extensions (in a different way). I'm in favor of the Manifold-way, but I've found a case that I think isn't possible with Manifold (or is it?).
With Lombok, an
ExtensionMethod
annotation is added for each class where you would use the extension methods. It is possible to add this:@ExtensionMethod({ StringUtils.class })
. This will make all methods from the (in my case) apache commons StringUtils class available as extension methods, even though all methods in theStringUtils
class are just normal methods, without any annotations.I'm not sure if something like this is possible with Manifold. I would like to use those methods as extension methods, without having to create an extension class myself, which delegates all methods to the
StringUtils
class. (However, I'm not sure what would happen with name clashes).Another useful class which could be used as an extension is
java.nio.file.Files
.It would be nice if we could configure somewhere that we want to use a class as an extension.
In the
Files
class, not all methods are applicable toPath
s (some have an equivalent with aString
parameter) , so maybe only the methods for which the first parameter is the same as a specified type could be taken into account.This might be a long shot and not be possible at all.
The text was updated successfully, but these errors were encountered: