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