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

Rename assertType into either validateType or isType #68

Closed
kungfooman opened this issue Dec 2, 2023 · 1 comment · Fixed by #98
Closed

Rename assertType into either validateType or isType #68

kungfooman opened this issue Dec 2, 2023 · 1 comment · Fixed by #98
Assignees
Labels
code generation Everything related to code generation type error reporting Everything related to type error reporting in UI

Comments

@kungfooman
Copy link
Owner

kungfooman commented Dec 2, 2023

This may cause a somewhat bigger refactor, because I'm no longer happy about the name "assertType" - IMO it should be called either validateType or - even shorter - isType - "assert" implies it will throw on wrong types, but it doesn't.

And then I'm also contemplating to rename the validate*-functions into assert*-functions and actually make them throw type errors, so we can merge certain types into one longer type error string.

I specifically think about: customValidations-for-entity.mjs

Example:

image

What I want to see here is simply: Entity#constructor> customValidation failed: x is NaN

@kungfooman kungfooman self-assigned this Dec 2, 2023
@kungfooman kungfooman added code generation Everything related to code generation type error reporting Everything related to type error reporting in UI labels Dec 2, 2023
@kungfooman kungfooman changed the title Rename assertType in either validateType or isType Rename assertType into either validateType or isType Dec 5, 2023
@kungfooman kungfooman mentioned this issue Dec 28, 2023
1 task
@kungfooman
Copy link
Owner Author

I pretty much see two ways to unify warnings:

  1. throw new Error('x is NaN') in combination with try / catch
  2. Giving each function a warn method, the "parent" will just append all the calls to this callback

I'm tending to (2) since (1) may cause performance issues. I can also imagine that (2) will reduce circular dependency a bit, which is very welcome aswell, tracked in #54 (because we can remove the warn import declarations)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
code generation Everything related to code generation type error reporting Everything related to type error reporting in UI
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant