Hi Christopher, Lukas, guys,

>Why confuse users with this artificial distinction (static vs contextual) 
between Factory and Executor? [...]

I agree. It confuses me too. 

> I also personaly don't like names like "Factory", "Executor", etc. While 
I reckon they are short, 
> they are too broad/generic and in a complex application do not 
immediately make the link 
> to jOOQ. They also don't help auto imports, code navigation, Google 
searches (there are many 
> generic classes with the same name), etc. In my view, a name like 
JOOQFactory [...]

Here, my opinion is different: for me one or another is quite ok. Java 
packages are also for this purpose.
If I look how many "Configurations" class I have in the class path: at 
least 14 (derby,javax.security,testng,jooq,spring,etc...)

I like how Eclipse Jetty name the web server component class: "Server" :) 
In opposition to tomcat where the web server is actually called "Tomcat". 
It is ok. too.

My 2 cents.

greetings
Simone


Il giorno domenica 31 marzo 2013 22:39:24 UTC+2, Chrriis ha scritto:
>
> Hi Lukas,
>
> I have a(nother?) silly question.
>
> Quoting you:
> "While Factory is all static, Executor initialises objects with a 
> Configuration. In fact, Executor and Factory share a lot of API, even if 
> informally by convention. This leads to things like 
> executor.fetch(Factory.select()) being the same as 
> executor.select().fetch()".
>
> Why confuse users with this artificial distinction (static vs contextual) 
> between Factory and Executor? Why not put all the static methods of Factory 
> in the Executor class and get rid of Factory (and static import Executor)?
>
> Also, I don't think Executor is a good name. It is the starting point of 
> creating a query and that should be obvious from the name. Moreover, the 
> query that Executor allows to build will eventually be transformed to a 
> String (getSQL()): it is not necessarily executed, it is more like a 
> factory. I think the name "Factory" is way better than "Executor" (no 
> matter whether you consider the context-aware methods or static ones, that 
> I just suggested to merge in one single class).
> I also personaly don't like names like "Factory", "Executor", etc. While I 
> reckon they are short, they are too broad/generic and in a complex 
> application do not immediately make the link to jOOQ. They also don't help 
> auto imports, code navigation, Google searches (there are many generic 
> classes with the same name), etc. In my view, a name like JOOQFactory would 
> be unambiguous: we would know what it creates just from the name and there 
> would be no name collisions.
>
> Please let me know what you think!
>
> -Christopher
>
>
Il giorno domenica 31 marzo 2013 22:39:24 UTC+2, Chrriis ha scritto:
>
> Hi Lukas,
>
> I have a(nother?) silly question.
>
> Quoting you:
> "While Factory is all static, Executor initialises objects with a 
> Configuration. In fact, Executor and Factory share a lot of API, even if 
> informally by convention. This leads to things like 
> executor.fetch(Factory.select()) being the same as 
> executor.select().fetch()".
>
> Why confuse users with this artificial distinction (static vs contextual) 
> between Factory and Executor? Why not put all the static methods of Factory 
> in the Executor class and get rid of Factory (and static import Executor)?
>
> Also, I don't think Executor is a good name. It is the starting point of 
> creating a query and that should be obvious from the name. Moreover, the 
> query that Executor allows to build will eventually be transformed to a 
> String (getSQL()): it is not necessarily executed, it is more like a 
> factory. I think the name "Factory" is way better than "Executor" (no 
> matter whether you consider the context-aware methods or static ones, that 
> I just suggested to merge in one single class).
> I also personaly don't like names like "Factory", "Executor", etc. While I 
> reckon they are short, they are too broad/generic and in a complex 
> application do not immediately make the link to jOOQ. They also don't help 
> auto imports, code navigation, Google searches (there are many generic 
> classes with the same name), etc. In my view, a name like JOOQFactory would 
> be unambiguous: we would know what it creates just from the name and there 
> would be no name collisions.
>
> Please let me know what you think!
>
> -Christopher
>
>

-- 
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.


Reply via email to