Hi Christopher,
2013/4/1 Christopher Deckers <[email protected]>:
> Hi Lukas,
>
>> Topic #1: Static vs. contextual Factory methods
>> ===============================================
>>
>> Things used to be the way you proposed in jOOQ 2.x. I.e. static and
>>
>> contextual methods were mixed in a single Factory. The problem this
>> cause was an essential problem for a fluent API. Because in Java,
>> static and instance methods occupy the same namespace, Query factory
>> methods were restricted to being contextual.
>
> I was wondering if the same method could be both contextual and static, but
> I am not sure whether there are so many cases that justify it. Since it used
> to be that way (2.x) you have more practical experience so I can't really
> argue.
I'm not sure how the same method could be both contextual and static.
You can't do this in Java:
class X {
static void x() {}
void x() {}
}
Of course, it would be possible to make the "static version" take the
context as an argument, but that would result in an awkward DSL entry
point:
class X {
static void x(Configuration c) {}
void x() {}
}
>> So, there is a relevant use-case for duplicating the API for query
>> construction into a static and a contextual part.
>
>
> I wonder then: could the query creation be fully static (like a capture of
> the user's declarations) and only its rendering/execution be contextual? Or
> are there cases where to represent the query you need context? And in that
> latter case, can't this just be postponed to execution/rendering time?
> Because maybe you should just have everything in the (current) Factory and
> create the Executor (whatever the name is) without fluent call, only a
> QueryPart parameter and 2 methods:
>
> Executor executor = new Executor(<context_params>, QueryPart);
> executor.getSQL()
> or
> executor.execute()
I would really really regret losing the ability to just append
".fetch()", ".execute()", and all the other many methods to a Query /
ResultQuery in a fluent style. I had given this much thought at the
beginning of jOOQ 3.0, because it would be the easiest solution to
this problem. But it would be a huge loss of functionality and fluency
for jOOQ. So there must be a way to construct Query / ResultQuery
objects in a contextual way.
Other APIs (such as QueryDSL in Java, SLICK in Scala, LINQ in .NET)
put less weight into this argument. Their APIs are more "polluted"
with host language elements, such as the "new" keyword. One of jOOQ's
key features is to make users really feel as if typesafe inline SQL
was possible in Java.
Of course, these arguments don't exclude alternative ways to execute
things. Already today, you can do:
Executor executor = new Executor(<context_params>);
executor.execute(query);
executor.fetch(resultQuery);
executor.batch(query1, query2).execute();
But as I said, you can also do:
executor.select().from(...).where(...).fetch();
Which I find really nice...
>> Topic #2: "Executor" as a name
>> ==============================
>> An alternative solution to this problem would be to add a
>> static "with" keyword to the Factory, with which an "Executor" could
>> be created (let's keep calling it Executor and rename it later).
>
>
> If my suggestion above has counter arguments, then this could be a possible
> fallback. But I would prefer to have some feedback on my suggestion before
> elaborating on that one :)
It has. Strong and emotional ones :-) So I'm looking forward to your
elaboration.
>>
>> Topic #3: Factory and Executor as short names in general
>> ========================================================
>>
>> Even then, you'll probably static-import
>> org.jooq.impl.Factory.*;
>
>
> Yes, this is the rule that probably makes your argument more valid.
> My experience is that everytime I use a "List" and I ctrl+shift+o and
> Eclipse asks me whether I mean "java.util.List" or the
> deprecated/outdated/irrelevant "java.awt.List" instead of auto importing
> irritates me.
I know. I hate the java.awt.List as much as you do.
>>
>> - Table (Swing, probably?)
>
>
> Bad choice, all Swing components start with J, and most libraries that ship
> Swing components kepts that convention. JTable, JCheckBox, even JWebBrowser
> ;)
"J" ... true, I forgot. Well, ok, I have these "Table" types on my classpath:
- ch.epfl.lamp.compiler.msil.util.Table
- com.google.common.collect.Table
- javax.persistence.Table
- liquibase.database.structure.Table
- org.apache.batik.svggen.font.table.Table
- org.apache.fop.fo.flow.table.Table
- org.h2.table.Table
- org.hsqldb.Table
And many others
> Also try in your Eclipse workspace ctrl+T and then "javax.swing.*Factory":
> none are just "Factory".
I have:
- net.sf.cglib.proxy.Factory
- org.apache.derby.iapi.db.Factory
- org.hamcrest.Factory
- sun.org.mozilla.javascript.internal.xml.XMLLib.Factory
And if I'm not mistaken, Apache XMLBeans generates a Factory class for
every XSD type. So I think people can live with another
org.jooq.impl.Factory :-)
>> We could discuss a rename from Factory to JOOQ or something like that,
>> of course. But I will need very compelling reasons to re-write the
>> whole manual and explain to everyone that the Factory has been
>> beautified :-)
>
> Honestly, if the API only has such naming issues (whether we agree or not),
> then the goal of having a solid API is reached :)
Thanks. I take that as an "I give up (on the Factory name discussion)" :-)
Cheers
Lukas
--
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.
