Yes, that would solve the problem. Although I have to wonder, how is
this any better than having a public constructor?
Jeff
On Thu, Apr 1, 2010 at 10:08 AM, Max Ross (Google)
<maxr+appeng...@google.com> wrote:
> Hi Jeff,
>
> Note that DatastoreServiceConfig exposes a withDefaults() method.
> FetchOptions has one too but it's package protected. We didn't expose it
> because FetchOptions isn't required for many low level datastore calls and
> we didn't see why users would want to create one if they didn't plan to
> adjust the offset, the limit, the prefetch size, etc. We didn't consider
> your use case though, and it makes perfect sense. Unless there's some other
> aspect of the Builder pattern that is getting in your way that you have
> explained, I think we could easily address your concern if we exposed
> FetchOptions.withDefaults(). Is that right?
>
> Thanks,
> Max
>
>
> On Thu, Apr 1, 2010 at 3:07 AM, Jeff Schnitzer <j...@infohazard.org> wrote:
>>
>> This is a genuine, heartfelt plea: The Builder pattern
>> (DatastoreServiceConfig, FetchOptions) makes code extra annoying when
>> layering an API on top of the low-level API.
>>
>> Let's say you are writing some code by hand that creates a
>> FetchOptions with a limit and an offset:
>>
>> FetchOptions opts = FetchOptions.Builder.withLimit(100).offset(20);
>>
>> Pretty straightforward when typing it out by hand, but the lack of
>> orthogonality between withLimit() and limit() is a PITA when you're
>> trying to automate the creation of a builder. The problem is, you
>> can't start with a "blank" FetchOptions. The result is we end up
>> writing lots of code like this:
>>
>> if (limit != null)
>> {
>> if (opts == null)
>> opts = FetchOptions.Builder.withLimit(limit);
>> else
>> opts = opts.limit(limit);
>> }
>>
>> This wouldn't be necessary if FetchOptions.Builder had a "create()"
>> method that would produce a blank FetchOptions. Or if FetchOptions
>> had a public constructor. Or if FetchOptions was an interface or even
>> a nonfinal class.
>>
>> I notice that DatastoreServiceConfig is following in the path of
>> FetchOptions. My initial reaction was Noooooo! :-)
>>
>> Thanks for listening,
>> Jeff
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Google App Engine for Java" group.
>> To post to this group, send email to
>> google-appengine-j...@googlegroups.com.
>> To unsubscribe from this group, send email to
>> google-appengine-java+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/google-appengine-java?hl=en.
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Google App Engine for Java" group.
> To post to this group, send email to google-appengine-j...@googlegroups.com.
> To unsubscribe from this group, send email to
> google-appengine-java+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/google-appengine-java?hl=en.
>
--
You received this message because you are subscribed to the Google Groups
"Google App Engine for Java" group.
To post to this group, send email to google-appengine-j...@googlegroups.com.
To unsubscribe from this group, send email to
google-appengine-java+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/google-appengine-java?hl=en.
