It would only break tapestry of you were accessing properties of your query object from your template or via property expressions in bindings. So if your component had a limit property that was bound to the query's limit, then that might break.
GATAATGCTATTTCTTTAATTTTCGAA > On Oct 9, 2014, at 2:08 PM, Michael Gentry <mgen...@masslight.net> wrote: > > Yeah, I don't know if changing setXyz to *not* return 'void' would > break things (like Tapestry). That would be a huge downer. > >> On Thu, Oct 9, 2014 at 3:03 PM, Andrus Adamchik <and...@objectstyle.org> >> wrote: >> I thought of that. Unfortunately "setXyz" is a 'java bean' setter, so we'll >> be redefining one of the most established Java conventions. >> >> Andrus >> >>> On Oct 9, 2014, at 2:51 PM, Michael Gentry <mgen...@masslight.net> wrote: >>> >>> I don't know if it will be confusing or not. At least with the >>> current method names, I can type query.set[ctrl+space] and let Eclipse >>> give me a list of set* method names to choose from (same applies for >>> get*), but that option won't be available with the new chainable API. >>> Part of me thinks just make setFetchLimit() return 'this' (at least >>> where it makes sense to preserve existing API): >>> >>> query.setFetchLimit(100).setDistinct(true); >>> >>> You could continue that in the model objects, too: >>> >>> person.setFirstName("John").setLastName("Doe"); >>> >>> mrg >>> >>> >>>> On Thu, Oct 9, 2014 at 1:31 PM, Andrus Adamchik <and...@objectstyle.org> >>>> wrote: >>>> >>>>> On Oct 7, 2014, at 9:30 PM, Michael Gentry <mgen...@masslight.net> wrote: >>>>> >>>>> On Tue, Oct 7, 2014 at 6:44 PM, Aristedes Maniatis <a...@maniatis.org> >>>>> wrote: >>>>>>> That said, if returning this is the direction we're going, then really >>>>>>> all >>>>>>> the currently void methods in SelectQuery should do the same thing - >>>>>>> like >>>>>>> addOrdering for example. >>>>>> >>>>>> >>>>>> Correct, but we also need to gracefully deprecate the old methods and >>>>>> make new fluent ones. >>>>> >>>>> I was looking at the changes and was wondering if we really need to >>>>> deprecate the old methods. Can't setFetchLimit() live along with >>>>> limit()? >>>> >>>> I suspect having both will be rather confusing. Initially I even wanted to >>>> leave SelectQuery alone and implement all the new ideas in a separate >>>> query class (ObjectQuery?), but since we've already made a bunch of >>>> changes to SelectQuery in the same direction, I ended up with a massive >>>> change to the existing class. >>>> >>>> Andrus >>