> - Being the single point of entry for the jOOQ DSL So it should be Jooq. Or JOOQ if you will (I don't care that much about letter case).
> - Being the single "factory" for constructing jOOQ QueryParts, functions, > bind values, etc. I think the factory aspect is a merely technical one; for classes that form an interface to the outside world, I think that the class should be named to reflect the reason why it's being used from there, i.e. its purpose. The purpose of the class is setting up an SQL-alike DSL. So... maybe org.jooq.DSL. Or org.jooq.SQL (I found that proposal intriguing, the example code there would fit well in a piece of code that constructs SQL only as a minor task and that doesn't want to import all of the class). I'm not sure whether SQL would collide with SQL classes from other packages. I now agree that googling isn't a too big issue since jooq as a search keyword narrows the result set nicely. I thought that might be a huge issues, but... no it isn't :-) For static imports, the class name doesn't matter that much. Even Factory would be alright though I'd think it's the wrong abstraction level and slightly misleading first-time readers about its true purpose. But then renaming the class might cause more trouble than renaming it... can't really judge that very well. Regards, Jo -- 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.
