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

Add collections.SymDiff #5410

Closed
bep opened this Issue Nov 6, 2018 · 6 comments

Comments

Projects
None yet
2 participants
@bep
Member

bep commented Nov 6, 2018

See #5400

Alias: symdiff

@bep bep added the Enhancement label Nov 6, 2018

@bep bep added this to the v0.51 milestone Nov 6, 2018

@bep bep self-assigned this Nov 6, 2018

@kaushalmodi

This comment has been minimized.

Member

kaushalmodi commented Nov 6, 2018

bep added a commit to bep/hugo that referenced this issue Nov 6, 2018

@kaushalmodi

This comment has been minimized.

Member

kaushalmodi commented Nov 6, 2018

Looking at this, makes me think.. may be you should break it out into a separate Go library for Set Theory. That way it will open it up for more contributions, and you just create aliases for the methods in Hugo.

@bep

This comment has been minimized.

Member

bep commented Nov 6, 2018

Hugo's type handling is, in general, not useful outside of Hugo.

@kaushalmodi

This comment has been minimized.

Member

kaushalmodi commented Nov 6, 2018

Thanks, I was reading the PR in hurry and missed that.

Or.. I think I don't know what I missed. I reread the PR, and it seemed generic enough. Isn't type handling good, usually?

bep added a commit to bep/hugo that referenced this issue Nov 6, 2018

bep added a commit to bep/hugo that referenced this issue Nov 6, 2018

bep added a commit to bep/hugo that referenced this issue Nov 6, 2018

@bep

This comment has been minimized.

Member

bep commented Nov 6, 2018

Isn't type handling good, usually?

That's a very generic statement to have an opinion either way about. Go 2 will probably come with Generics, which may or may not make our lives easier, but there are a couple of reasons why these template funcs works best as ... template funcs:

  • We use reflect so we can take any type (Page, int, string ...) and ... complement it etc. This is, of course, in general useful, but isn't very ... pretty to look at.
  • The way Go template funcs works makes us make these slightly odd APIs (re. yesterdays discussion). That works in templates, but we would do it differently if a pure Go API.
  • And finally, since the different decoder libraries we use (JSON, TOML, YAML) all have their own conception of which types to use for numeric values, we also do some conversion of those etc. which we probably would not care about in a general library.
@kaushalmodi

This comment has been minimized.

Member

kaushalmodi commented Nov 6, 2018

Thanks for the detailed explanation; makes sense!

bep added a commit to bep/hugo that referenced this issue Nov 6, 2018

@bep bep closed this in #5411 Nov 6, 2018

bep added a commit that referenced this issue Nov 6, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment