jOOQ / jOOR

jOOR - Fluent Reflection in Java jOOR is a very simple fluent API that gives access to your Java Class structures in a more intuitive way. The JDK's reflection APIs are hard and verbose to use. Other languages have much simpler constructs to access type meta information at runtime. Let us make Java reflection better.
http://www.jooq.org/products
Apache License 2.0
2.8k stars 377 forks source link

Allow inheritance for Reflect class #115

Closed NxDs closed 3 years ago

NxDs commented 3 years ago

Allow inheritance for Reflect class by changing constructor's access modifier from private to protected. This would allow us to extend Reflect class with more methods while keeping the original jOOR as dependency instead of forking the project and extend it there.

lukaseder commented 3 years ago

Thanks for your suggestion. I'm always very reluctant to open up implementations for extension because no matter what you're trying to do, it's almost always the wrong approach to doing it. Rationale here:

In other words, patching jOOR is just as good/bad as extending it if it wasn't designed for extension.

Much rather than discussing visibilities, how about discussing what you're actually trying to do? Maybe, we can support that in jOOR, instead?

NxDs commented 3 years ago

Thanks for replying, the idea was to be able to extend Reflect with project-specific functionalities that wouldn't otherwise make sense in a generic library (i.e. some static fields initialized with reflection, etc). It's the kind of things that would usually go in a separate ReflectionUtils class so my idea to approach it was to simply extend Reflect and use the extended class as a typical ReflectionUtils with all the project related stuff while at the same time keeping the fluent functionalities offered by Reflect, a sort of class containing all it's needed for that particular project related to reflection.

lukaseder commented 3 years ago

Thanks for the explanation. I see that this is something that may appear tempting, but opening up internal API for users to extend is a very slippery slope. jOOR will have to maintain it like any other public API backwards compatibly, completely waiving all the benefits of encapsulation and other aspects of API design. I'm actually surprised that Reflect isn't a final class, like most classes I create - especially given that its constructors are private.

I think you'll need to find a different way to implement your project specific reflection, other than through inheriting a third party library class. This seems to mostly be about notation (reflect.myMethod(args) instead of myMethod(reflect, args)), which is a good example where other languages' extension methods really shine. Inheritance is the wrong tool to achieve such notation convenience.