> 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. > 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. > e) by changing the API to be camel-case with an upper-case initial letter: > Select(), Case(), OrderBy() Workable but an incompatible change. > 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. select() might work. choice() could even be an even better, erm, choice. Or maybe 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.
