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

Getter function vs. property for image data settings #58

Open
adroitwhiz opened this issue Mar 16, 2021 · 0 comments
Open

Getter function vs. property for image data settings #58

adroitwhiz opened this issue Mar 16, 2021 · 0 comments

Comments

@adroitwhiz
Copy link

adroitwhiz commented Mar 16, 2021

I remember seeing a bit of discussion about this somewhere, but can't find it by searching.

What's the rationale for the image data settings being accessible via a getter function (getImageDataSettings) instead of via a read-only attribute or just as individual attributes on ImageData directly?

While getImageDataSettings does match the canvas contexts' getContextAttributes API, I would argue that an ImageData object is sufficiently different from a canvas context that it may be better for the APIs to differ:

  • A canvas context has state, and is long-lived (you create it then reuse it). You're therefore more likely to just store the context attributes, or at least the ones relevant to you, in the same place that you store the canvas context, instead of repeatedly calling getContextAttributes. ImageData objects are less stateful--while you can mutate their data, the API is designed around being able to create them easily and often.
  • A canvas context has many writable properties which affect rendering state, so it makes sense to place the non-writable ones behind a getter function to avoid confusion. All ImageData properties are readonly, so there's no such confusion.
  • Adding on to the above point, ImageData's existing properties (width and height) are in the same category as the one(s) being added here in that they are purely "descriptive", so it doesn't make sense to arbitrarily split further properties into a dictionary behind a getter function.
  • Feature detection is less futureproof if the new properties are behind a getter function. If, for instance, colorSpace was a property on ImageData, then you could query support for it with ImageData.prototype.hasOwnProperty('colorSpace'). While you can query support for the existing proposal with ImageData.prototype.hasOwnProperty('getImageDataSettings'), this doesn't actually tell you which settings are supported. If more settings are added in the future (e.g. premultiplication), then you'll have to call ImageData.prototype.hasOwnProperty('getImageDataSettings') to check if the settings dictionary is supported in the first place, construct an ImageData object and call getImageDataSettings on it if so, then call hasOwnProperty on the settings dictionary to see which specific settings are supported.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant