Skip to content

Simplified API for custom types #73

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
wants to merge 18 commits into
base: main
Choose a base branch
from

Conversation

JohannesMeierSE
Copy link
Collaborator

This PR contributes a simplified API to enable users of Typir to define and use their project-specific custom types. Features of custom types as designed in this PR:

  • Custom types have custom properties ("data") including primitive values, Typir types and nesting/grouping (sets/arrays/maps and recursion)
  • TypeScript-safe descriptions for these properties with TypeScript-generics
  • ensure uniqueness for custom types
  • Cyclic dependencies of the given types for type properties are handled (see custom-cycles.test.ts and custom-selectors.test.ts)
  • specify rules for conversion, sub-type, names, identifiers, inference and validation (usually for all custom types OR for single ones)

For some more fixes/features of this PR beyond custom types, see the CHANGELOG.md.

Open questions to discuss during the review:

  • I needed to introduce LanguageService.isLanguageNode(node: unknown): node is LanguageType, which is used once and only for a detail (which has some relevance nevertheless): Is there a better solution? Should we make it optional (or is the default implementation OK)? For me, this feels not like a perfect solution.
  • There is one limitation for custom types: You cannot use simple string values for TypeSelectors (in order to specify properties of type Type), since they cannot be distinguished from string values for primitive properties. In my eyes, that is a reasonable limitation, since you will get a TypeScript error, if you try to do that.
  • Since custom types have builtin support for circular types, you have to call getTypeFinal(): Type|undefined on the initializer always, even in cases, where it is not required, since your custom type has no types as properties or you know, that all depending types are already available. Even in these cases you need the "work-around" with const myCustomType = ...finish().getTypeFinal()!;. An idea would be to provide SimpleCustomTypes (without support for circular types) and ComplexCustomTypes (with support for circular types) and the user of Typir has to select the appropriate solution for the current use case.
  • Another issue, which is not directly related to custom types: undefined is not supported as result to be returned by an inference rule. You need to return InferenceRuleNotApplicable, if the rule is for another case, or an InferenceProblem. Should we support undefined as well? That might simplify some things.

Hints for the review:

  1. Try to get the general idea of this approach for custom types in order to evaluate, whether this approach is the one to go. Some more polishing could be done, when we decided on the way to go.
  2. Look at the examples in custom-example-matrix.test.ts and custom-example-restricted.test.ts first to get an idea, how the API works.
  3. The other four files with test cases for custom types are quite specific, but might give an impression, what is possible with custom types.
  4. If you review the implementation commit-by-commit (which might be useful in general), notice, that the earlier commits develop custom types step-by-step including some reworked parts. Don't spent too much time to understand each detail in custom-type.ts and custom-definitions.ts 🙂

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

Successfully merging this pull request may close these issues.

1 participant