It is kind of hard for us to detect and prevent all possible conflicts in the *downstream* code like this. Hope this is not something that completely prevents the use of Cayenne with Scala though.
Andrus > On Nov 17, 2014, at 7:59 PM, David Feshbach <[email protected]> wrote: > > One possible reason to avoid "eq" and "ne" is that they are already methods > on Scala's AnyRef. When using Cayenne in Scala, I get errors like this in my > IDE: >> org.apache.cayenne.exp.Property[String] and String are unrelated: they will >> most likely never compare equal > > On Nov 17, 2014, at 9:09 AM, John Huss <[email protected]> wrote: > >> I definitely do not want "is", especially since the the negated operation >> has to be consistent - "eq" and "ne" works. >> >> I like "where". >> >> I would stick with "select" since we have SQLSelect and ObjectSelect. >> Unless we have good alternatives names for those too. >> >> >> On Mon, Nov 17, 2014 at 8:42 AM, Andrus Adamchik <[email protected]> >> wrote: >> >>> Cayenne Property class is using 'eq' for the same reason. >>> >>>> On Nov 17, 2014, at 5:07 PM, Mike Kienenberger <[email protected]> >>> wrote: >>>> >>>> Chainable fest testing assertions use "isEqualTo" to avoid confusion >>>> with "equals" >>>> >>>> >>>> On Mon, Nov 17, 2014 at 9:01 AM, Michael Gentry <[email protected]> >>> wrote: >>>>> On Sun, Nov 16, 2014 at 9:13 AM, Andrus Adamchik < >>> [email protected]> wrote: >>>>>>> "eq" with "is", >>>>>> >>>>>> I actually prefer "eq[uals]". Considering all other operations in the >>> Property class, "is" creates a bit of asymmetry IMO. >>>>> >>>>> The problem with "equals" is it has other connotations in Java, >>>>> otherwise I'd like it just fine. Of course, you could argue that "is" >>>>> also has other Java connotations (JavaBeans is* method naming >>>>> convention). >>>>> >>>>> mrg >>>> >>> >>> > >
