Hi Joseph, 2016-01-04 23:01 GMT+01:00 <[email protected]>:
> Hi Lukas > > Thanks a lot for your answer :) > > My use case is explained there > https://groups.google.com/forum/#!topic/jooq-user/I9iLbMQNN8o => I want > to have the current domain classes extend the latest version. > OK. I still think it's a bad idea in the long run :-) > Regarding your worry about internal API leak, well, this is right but > anyway already the case (for anything not private - and thus at least > package private). > Why? If you don't subtype, all you can see from the outside of a table reference is public stuff...? And as I said, you shouldn't subtype :) However, to link with your discussion on the next model generation > approach, maybe the new one could favor composition by extending some > interface and then, internally, just have a private instance of the actual > impl and delegate to it. It would be pretty easy to do I guess and feels > like rather clean as far as I see it. > Interfaces can't have attributes, so that would require adding nasty parentheses behind every reference: CATALOG().SCHEMA().TABLE().COLUMN() Unless I'm missing something? > Back to the initial issue, I don't believe making the class final on top > of having a private constructor would be any better: I already had to > change the generated class (to open the constructor) and nothing could stop > me from doing so with a final class. So personally I would not try to > "close" too much stuff which can easily be opened up if needed. > Yes it certainly is better from our point of view. It's a disclaimer. A clear message: "You're not doing what we expected you to do, or what we designed this for. If you don't get in touch and discuss the use-case (which allows us to actually *implement* the feature that you're looking for properly), then it'll be entirely your own fault when it breaks." Look at it from the bright side. If you hadn't encountered these limitations, you might not have gotten in touch, we would not have had this conversation, and neither of us would have learned. And I'm pretty sure, your code would have broken some months down the line, when you upgrade. The more limitations you encounter, the more probable it will be that you get in touch. I always prefer these conversations over quick wins. Of course, if you do insist, you can change anything you want, and one more "final" will not impress you. That's perfectly OK. On the bigger picture, is there any technical issue with extending the > FlywayTest class ? > Yes. Don't. :) Although, right now, there probably isn't. > It doesn't feel like it (no AOP, proxy or whatnot around, no funky cache > or internals as far as I see it). If it's the case, a short explanation in > the generated class would be nice > In *every* class? ;-) But it is a good idea to add a manual section when this is implemented: https://github.com/jOOQ/jOOQ/issues/4902 -- You received this message because you are subscribed to the Google Groups "jOOQ User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
