2013/6/24 Durchholz, Joachim <[email protected]>
> > As you can see, there are a lot of caveats when > > implementing an internal domain specific language > > (as opposed to an external one). [...] > > I currently see four ways to solve 5) > > > > a) by using synonyms > > Not good, because the synonyms have to be looked up in the API doc. > > > b) by appending "disambiguators" such as case_ or case$ or case > > Workable but ugly. > > > c) by introducing artificial spelling, such as casë, casǝ, casɇ ;-) > > Cute :-) > But doesn't solve the problem, since you still have to look up the > spelling variation employed in each specific case. Not when leveraging auto-completion. But that wasn't such a serious proposition anyway ;-9 > > d) by changing the API to be all-uppercase: SELECT(), CASE(), ORDER_BY() > > Workable but awkward to type. > Also awkward to read. Lowercase letters are easier to distinguish than > uppercase letters (because the outlines have more variation I think). > And an incompatible change, too. If this is introduced, camelCasing and UPPER_CASING would be maintained in parallel (see the other mails). This leaves the choice of casing up to the user. I agree about the typing, if not using syntax auto-completion in an IDE. On the other hand, jOOQ is a very IDE-friendly API... > > e) by changing the API to be camel-case with an upper-case initial > letter: Select(), Case(), OrderBy() > > Workable but an incompatible change. Again, there would be no incompatibility, as these API variants can be maintained in parallel. > > Any other ideas? > > None. You've been quite thorough here. > > I see a slightly different issue at work here: Most replacements are > more-or-less obvious choices, but decode() is a nonobvious replacement for > IF/CASE. > It's essentially perpetuating the misnaming of Oracle's DECODE(). It > sort-of makes sense to do it that way, but it won't be understood or > appreciated by those who work in other languages. Given the tool wars many > people entertain, reusing Oracle nomenclature might even mark you as > adherent of one particular camp. I am. Thus, Oracle is supported particularly well by jOOQ. But you are right. In this case, DECODE() wasn't the best choice. > select() might work. choice() could even be an even better, erm, choice. > Or maybe choose(). Yes, "choose" would be much better. Given that "else" is mapped to "otherwise", "choose" wouldn't be too bad. This would at least remind of XSL or JSTL. Both XSL and JSTL also know "then", so it would at least be more consistent. I guess, a short-term solution would include either "case_" or "choose" -- 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.
