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 >>>>> >>>> >>> >> >
