> Yeah, I don't know if changing setXyz to *not* return 'void' would
> break things (like Tapestry). That would be a huge downer.
Just saw something cool at WOWODC. Instead of changing setXyz to return "this",
people would generate a Builder class for each Java class that has fluent
methods for every query:
Entity e = Entity.Builder
.attribute1("a")
.attribute2("b")
.rel1(someObject)
.rel2(someOtherOBject).
.build(context);
What may not be immediately obvious is that this also forces setting all
mandatory relationships ("build" method is only available on an object returned
from the last mandatory relationship method). I am not sure I personally have a
strong need for this API, but if you initialize your object on creation with
lots of attributes, this looks pretty neat actually.
Andrus
> On Oct 9, 2014, at 9: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
>>>>
>>>
>>
>
