Skip to content

Rename Save API for DataLoader to SaveDataLoader. #3019

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from

Conversation

codemzs
Copy link
Member

@codemzs codemzs commented Mar 19, 2019

towards #2991

@TomFinley
Copy link
Contributor

TomFinley commented Mar 19, 2019

I don't necessarily agree with this change. As far as I can tell, this PR was the result of an off hand comment by @eerhardt here.

I think it is confusing to have methods that have different results and return values and whatnot to be overloads, that is, have the same name, which is why I agreed with the other point here. But I think overlods that accept different types as parameters are fine and well established. (Indeed that's why overloads exist in the first place.)

Consider for an analogous situation, BinaryReader. Note all the Read* methods -- all differently named, all different return values. Now consider BinaryWriter. Basically one Write with different arguments. So the idea that there has to be a "master symmetry" . This loading and saving strikes me as rather similar.

It wouldn't be an absolute disaster if this PR was checked in of course, but I consider the original premise that led to this PR to be questionable. Also of course there is no actual issue where this is proposed, discussed, or anything else like this. Just an off handed question, not even really phrased even as a suggestion, about whether we should do this, where we didn't even as far as I tell think seriously about whether the answer to that question might be "no." (Clearly .NET SDK doesn't think so, as we see above!)

@TomFinley
Copy link
Contributor

Incidentally I am removing this from public surface in #3044. Maybe we close this @codemzs, and if you would be so kind as to review that one?

Copy link
Contributor

@TomFinley TomFinley left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this change is now obviated by #3044, since after discussions with @eerhardt and @yaeldekel as captured in #3025, we decided perhaps the more radical step of removing this entirely (as its presence is confusing, no matter what we name it)

@TomFinley
Copy link
Contributor

I think this change is now obviated by #3044, since after discussions with @eerhardt and @yaeldekel as captured in #3025, we decided perhaps the more radical step of removing this entirely (as its presence is confusing, no matter what we name it)

So, what I mean is, should we close this @codemzs ?

@codemzs codemzs closed this Mar 26, 2019
@ghost ghost locked as resolved and limited conversation to collaborators Mar 23, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants