> It's not obvious. It's subtle. You cannot actually > create a meaningful GalaContainer type, because a > GalaContainer will not contain Gala objects, it > will contain Apples, which defeats its purpose.
I agree that subclassing a nongeneric AppleContainer to create a GalaContainer doesn't work. GalaContainer isn't a subtype of AppleContainer, it cannot be because add(Gala) isn't Liskov substitutable with add(Apple). But the container of Galas wouldn't be allowed to be a subtype of the container of Apples, regardless of whether the classes involved are generic or not. At best, if Java allowed that, it would be another type hole in the language. So... I don't understand what problem that example presents that wouldn't be present without generics, or without generic instantiation. > Anyway, I feel that this discussion starts getting > a bit off-topic for the jOOQ User Group... :-) Ah well. > The various .sql() methods can be added to a DSL > API without using recursive generics. If you happen to have .sql in a class and there are subclasses, and .sql() is to return "this", then you'll need an override to change the result type. The exact same issues reappear in that situation: - If you need to change what .sql() does, you just tack on that boilerplate "return this;" and be done with it. The associated cost is nonzero but small. - If you don't need to change what .sql() does, you still need to override the function to change the return type. Which means a semantic-devoid override - that's a net cost, particularly if you have a large number of functions that "return this". - Using generics automates the override for the return type. You'd want to write a generic-parameter-instantiating subclass for each generic type to avoid imposing the burden of generic instantiation on library users, so we're again at boilerplate with a nonzero but small cost. I think the trade-off depends on how many subclasses inherit how many this-returning functions. If there is a huge number (fifty attributes in the base class that get inherited by several handful of subclasses), then generics are pretty much unavoidable. If there are very few inherited attributes, it doesn't pay off. Working with generics will also make the design scale to an arbitrary number of attributes and classes. That may or may not be a relevant consideration, depending on the future plans for any library that has to make that decision. -- 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/groups/opt_out.
