While I don't want us to devolve into Perl, still there's something to be said for having easy-to-understand API conventions that cut down the boilerplate. I think this also improves overall readability.
Not sure if "likeI" is too much though. I am fine with keeping 'likeIgnoreCase'. Andrus > On Nov 22, 2014, at 5:40 PM, Michael Gentry <[email protected]> wrote: > > I still prefer things to be spelled out. My personal philosophy is you are > writing code to be read, not writing code to be written. To me, it helps > when maintaining code or picking up someone else's code down the line. > > mrg > > > On Sat, Nov 22, 2014 at 6:43 AM, Andrus Adamchik <[email protected]> > wrote: > >> so, case sensitivity naming has its own inconsistencies already: >> >> ExpressionFactory.likeIgnoreCase(..) >> Property.likeInsensitive(..) // this is 4.0 API, we can change it >> >> I wonder if we should use the third shorter form going forward: >> >> likeI(..) # "I" is alluding to regex "i" flag. >> >> Thoughts? >> >> Andrus >> >> >> >>> On Nov 21, 2014, at 6:08 PM, Mike Kienenberger <[email protected]> >> wrote: >>> >>> Not only readability, but also picking the right options. >>> >>> For me, code completion on a method name is the quickest way to work >>> through chained query options. An enum argument is also workable, >>> but extra typing. But a generic type like int or boolean makes it >>> difficult to figure out what to specify without looking up the >>> documentation. >>> >>> On Fri, Nov 21, 2014 at 10:02 AM, Andrus Adamchik >>> <[email protected]> wrote: >>>> enum also makes it needlessly verbose :-/ >>>> >>>> But yeah, I take your point. >>>> >>>> >>>>> On Nov 21, 2014, at 5:56 PM, Michael Gentry <[email protected]> >> wrote: >>>>> >>>>> I'd avoid true/false for that purpose. We had the same thing in >>>>> orderings before I changed it to an enum. I'd specify it in the >>>>> method name or use an enum that makes sense when reading it. >>>>> >>>>> mrg >>>>> >>>>> >>>>> On Fri, Nov 21, 2014 at 9:47 AM, Andrus Adamchik < >> [email protected]> wrote: >>>>>>> So are you thinking something like: >>>>>>> Artist.ARTIST_NAME.contains("Van")? >>>>>> >>>>>> yep. >>>>>> >>>>>>> Also, what about >>>>>>> case-insensitive? >>>>>> >>>>>> Probably as a second true/false argument? I started to dislike the >> look of "likeIgnoreCase" recently :) >>>>>> >>>>>> Property.contains(string); >>>>>> Property.contains(string, true); >>>>>> Property.contains(string, false); >>>>>> >>>>>> >>>>>> Andrus >>>>>> >>>>>> >>>>>>> On Nov 21, 2014, at 5:33 PM, Michael Gentry <[email protected]> >> wrote: >>>>>>> >>>>>>> I 'like' this. >>>>>>> >>>>>>> So are you thinking something like: >>>>>>> Artist.ARTIST_NAME.contains("Van")? Also, what about >>>>>>> case-insensitive? >>>>>>> >>>>>>> mrg >>>>>>> >>>>>>> >>>>>>> On Fri, Nov 21, 2014 at 7:19 AM, Andrus Adamchik < >> [email protected]> wrote: >>>>>>>> Another API idea that I just had while analyzing boilerplate code >> of the client Cayenne apps. An argument to Property.like(..) (or second >> argument to ExpressionFactory.likeExp(..)) requires a full pattern to match >> against. So people would often write their own utility code to wrap a >> String in "%" signs. Cayenne can easily take care of this via the following >> methods: >>>>>>>> >>>>>>>> >>>>>>>> Property.contains(string); >>>>>>>> // same as Property.like("%" + string + "%"); >>>>>>>> >>>>>>>> Property.startsWith(string); >>>>>>>> // same as Property.like(string + "%"); >>>>>>>> >>>>>>>> Property.endsWith(string); >>>>>>>> // same as Property.like("%" + string); >>>>>>>> >>>>>>>> In addition to saving the user from String concatenation, these new >> methods can do proper symbol escaping, making "like" much safer to use. >>>>>>>> >>>>>>>> Andrus >>>>>>> >>>>>> >>>>> >>>> >>> >> >>
