2014-04-29 15:36 GMT+02:00 Garret Wilson <[email protected]>:
> On Tuesday, April 29, 2014 12:21:49 AM UTC-7, Lukas Eder wrote:
>>
>> ...
>>
>>> I would even go so far as to consider it bugs that the strategies
>>> require that "get" and "set" be provided in the output of <fieldSetter>and
>>> <fieldGetter>; and that the transform is applied to the "get" and "set"
>>> suffixes as well.
>>>
>>
>> How would you go about people not wanting "get" and "set" in their getter
>> and setter names?
>>
>
> Um... er... as they say in Brazil, "estou sem palavras"---I'm without
> words. Speechless. hehe At first I thought you were joking. I mean, if the
> number of people using "foo:bar" and "foo#bar" in the same table is like
> .1% of users, a use who doesn't want "get" in the getter name (is it still
> a getter, then?) is like .05% of users. (Numbers used for explanatory
> value, not for accuracy.)
>
Two very simple use-cases:
1. Someone prefers "is" over "get" for boolean getters
2. Someone prefers no verb at all. Yes, we're all slaves to JavaBeans. But
why? Why not just have:
interface SomeRecord {
// Setter
void SOME_COLUMN(int value);
// Getter
int SOME_COLUMN();
}
And then, there's this whole group of folks who follow suit with Martin
Fowler who proclaimed fluent setters that are prefixed with "with" (and
return "this", this is yet another pending feature request:
https://github.com/jOOQ/jOOQ/issues/2934)
And then, Scala developers use jOOQ, too. Without the useless "get" / "set"
/ "is" boilerplate, they can write even more fluent jOOQ interaction code.
Now. While you obviously don't agree with these arguments - which is fine,
I can see your point about the .1% vs. .05% - I've been maintaining this
beast for 5 years now, and believe me, I've seen my share of feature
requests, most specifically in the field of people not agreeing with
generator defaults. While jOOQ has hundreds of other great features,
somehow, everyone seems to have one or two flags to suggest that would make
"that difference". This is why we have these strategies, to avoid tons of
unmaintainable flags. In principle, you can override anything if it's that
important.
Of course, they may still have 1-2 flaws / bugs :-)
But this is very easily addressed, and at the same time addresses another
> issue I raised, namely that you shouldn't have to define both getters and
> setters when you know the general format of the property. jOOQ should add a
> property named <fieldProperty>. If defined, it determines what comes
> after both "get" and "set" in getters and setters, respectively. That is,
> if I set the <fieldProperty> transform to UPPER, then this produces
> getFOO() and setFOO() and I don't even have to define <fieldGetter> and
> <fieldSetter>. For that tiny fraction of people who don't even want "get"
> and "set" in their accessor names, then they can define <fieldGetter>and/or
> <fieldSetter>, which will override the rule in <fieldProperty> (or they
> don't even have to define <fieldProperty> at all). This solution
> therefore is even 100% backwards compatible. If you add it in the next
> version, no one even has to change their code if they want to continue
> using <fieldGetter> and/or <fieldSetter>!
>
That's a good idea! Thanks for bringing that up - and for bearing with me
;-). It would even set the default for <fieldMember>
I've registered #3222:
https://github.com/jOOQ/jOOQ/issues/3222
> See, the general rule should be, "make the default configuration work as
> expected for the 99.98% of normal use cases, and provide optional
> configuration for the .01% of users who want to break convention".
>
>
>>
>>
>>> OK, I'll use what I got sort of working. But can someone tell me what
>>> <fieldMember> applies to?
>>>
>>
>> It is used for member names in POJOs and also for method argument names.
>>
>
> Maybe you could point me to an example? I guess I haven't got to POJOs
> yet---I was thinking the ExampleRecord class was like a POJO.
>
These:
http://www.jooq.org/doc/latest/manual/code-generation/codegen-pojos/
> Anyway, Lukas, thanks so much for all your help and feedback on this. I've
> got jOOQ set up in our project now, and I've handed the database access
> part over to a teammate to convert some of our existing SQL to jOOQ. We'll
> see how it goes.
>
Good luck with that! Let us know how it goes!
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/d/optout.
