Skip to content

Include more JS primitives for Untagged variants #7147

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

Open
nojaf opened this issue Nov 5, 2024 · 2 comments
Open

Include more JS primitives for Untagged variants #7147

nojaf opened this issue Nov 5, 2024 · 2 comments
Assignees

Comments

@nojaf
Copy link
Collaborator

nojaf commented Nov 5, 2024

I'm trying to model blobParts of https://developer.mozilla.org/en-US/docs/Web/API/Blob/Blob#blobparts for the new WebAPI bindings.

@unboxed
type blobPart =
  | String(string)
  | Blob(blob)
  | ArrayBuffer(ArrayBuffer.t)
  | TypedArray(TypedArray.t<int>)

However, I cannot use ArrayBuffer.t and TypedArray.t in combination with the @unboxed.
Could some of these be extended?

@nojaf
Copy link
Collaborator Author

nojaf commented Nov 13, 2024

I'm hitting the limitations of @unboxed again for https://github.com/rescript-lang/experimental-rescript-webapi/pull/7/files#r1839785692

Modelling https://developer.mozilla.org/en-US/docs/Web/API/CanvasRenderingContext2D/fillStyle

It should be something like

@unboxed
type fillStyle =
  | String(string)
  | Gradient(canvasGradient)
  | Pattern(canvasPattern)

It would be great if I can input some sort of check for the unboxed via attribute, something like:

| @check("$0 instanceof CanvasGradient") Gradient(canvasGradient) // where $0 is the object in place.

@cometkim
Copy link
Member

Blob is a part of Web API (File API spec), not a JS primitive.

It is actually an outer class and has more complex semantics at the prototype level than JS primitives. Handling this safely will add tons of complexity to the compiler.

As we discussed before (rescript-lang/rescript-core#240), I think it's not a good long-term direction for the compiler to add specializations for specific environments, because it bloats the compiler code, reduces configurability, and limits future enhancements.

If it cannot be extended in a generalized way, it should be kept to a minimum as possible.

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

3 participants