Combine info and functional objects

[ajkannan]

This PR is in reference to #530.

Some questions that came up while I was coding:

• It might be nice to have factories for the objects (makes most sense for blobs, maybe for buckets and projects as well). That way users would only have to supply the service object once. Thoughts?
• Should we continue to expose ResourceManager.create(...) and ResourceManager.update(...)? Since the blob/bucket has a reference to the storage object, users can instead do something like Blob.of(storage, "b", "n").create() and existingBlob.update(newBlob). Another reason we may not want to expose that is because the user could provide conflicting ServiceOptions. For example, the storage service object could be based on options with retrying and the blob's service options may not have retries. Which set of options should be used (i.e. should there be retries) for when creating a new blob via resourceManager.create(someblob);?

If we decide to move ahead with the xxxInfo/xxx merge, then the following have have to be completed before merging this PR:

• Test that StorageExample and ResourceManagerExample work with the changes in this PR
• All code snippets in the JavaDoc and in the READMEs should be updated to reflect these changes.
• Make sure all new methods are covered (there are a couple create methods in Blob that need associated tests)

BigQuery will have to be changed, but since this is already a large PR, perhaps that can be done in a subsequent PR.

[ajkannan]

Also, it may be easier to get the gist of what I did by looking at the first commit (fe9de9c) first, since it's much smaller.

[mziccard]

It might be nice to have factories for the objects (makes most sense for blobs, maybe for buckets and projects as well). That way users would only have to supply the service object once. Thoughts?

Having the user to always provide the service object is quite annoying. Adding a factory is a solution but requires the user to write even more code just to instantiate an object.

Should we continue to expose ResourceManager.create(...) and ResourceManager.update(...)?

Given that we provide that methods as Project instance objects (even though I don't like very much having create as an instance method) I think we should no longer expose such methods. I left another comment on this but I think we should also expose list as a static method.

Another reason we may not want to expose that is because the user could provide conflicting ServiceOptions. For example, the storage service object could be based on options with retrying and the blob's service options may not have retries.

I don't see this as an issue.

BigQuery will have to be changed, but since this is already a large PR, perhaps that can be done in a subsequent PR.

If we decide to go this way I can take care of doing it in a separate PR.

[mziccard]

I also had a look at storage changes. I think this proof of concept is very good but I did not change my opinion, I still think this change does not increase the usability of our library and also creates some situations where service references are passed multiple times to a number of objects involved in the same operation (see storage batch and copy requests). My main points against are:

• I don't see this as an improvement in usability (but this is a strictly personal opinion)
• An object now contains both service stuff (options) and resource's data, should equals compare only resource data? Or also options? This is tricky and has no correct answer in my mind. I would prefer equals to only compare resource's data
• Classes grew in size, the code is by far less maintainable
• I don't like that the user must pass a service reference to a storage object and the also use the reference to issue a batch that contains storage objects:

Blob blob = Blob.of(storage, ...);
BatchRequest req = BatchRequest.builder().update(blob);
storage.submit(batch);

[ajkannan]

Closing this PR since we decided to go with the alternative in #572.