Skip to content
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

Agree a sensible API for filtering so we can reduce the risk of frequent breaking changes to signatures #661

Open
theotherphil opened this issue May 28, 2024 · 3 comments

Comments

@theotherphil
Copy link
Contributor

theotherphil commented May 28, 2024

What functions should exist, should we provide simple wrapper functions, what code structure do we want, and what docs need to exist to ensure discoverability.

Related: what’s our policy for breaking changes - what warrants a rename or signature change and what doesn’t.

@ripytide
Copy link
Member

Ditto #660 (comment) I think the gradient one liner functions are poor for readability and maintainability and should be deprecated.

@ripytide
Copy link
Member

ripytide commented May 28, 2024

I'd disagree with renaming filter_clamped to filter since shorter names are not always better names for code readability as the name filter hides that it clamps pixel sums unless you read the docs and so could become a foot-gun.

@ripytide
Copy link
Member

ripytide commented May 28, 2024

Not to mention that all the gradient functions all currently only support GrayImage, and not color images. Supporting any image pixel would require repeating filter_clamped()'s trait bounds on every one of the one-liner functions which is not very maintainable and not an easy API to learn for new users.

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

No branches or pull requests

2 participants