I see what you mean. Is possible, I'd like to hide such generic `queryParameter` methods to let users have a high-level API that is easily understandable.
What about this: Now we are using the `Arg0ToPagedIterable` class because we only need the first parameter passed to the method when creating a request for the next page. The second argument (the query parameters holder), is just the same object we use as a "marker" in the `IterableWithMarker`, so we pass it directly. This is convenient, but it does not have to be this way. We could have just a plain object `PaginationOptions` that did **not** extend the `BaseHttpRequestOptions`, just a plain object we use as the "marker to next page" and let the `ItetableWithMarker` return that obejct. Then we could have specific filter objects just like `DatacenterListFilters` with a method `pagination(PaginationOptions)` that configures the query parameters accoding to the pagination options. Up to this point is just the same as the last proposal you mentioned, but there is one small thing to change. We could change the `ToPagedIterable` to extend `ArgsToPagedIterable` instead. That would change the method to `markerToNextForArgs` and it would recieve not only the first argument passed to the method, but all arguments. There you could take the method arguments and also the `DatacenterListFilters` argument as passed by the user and just override in the latter the pagination options as they come from the `IterableWithMarker`. This is pretty much the same than your last proposal but without having to revuild the filter options object. In each iteration we should be just modifying its pagination parameters. WDYT? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-labs/pull/433#issuecomment-381879244
