Atdts: supporting <ocaml from ...> annotation #429
Conversation
|
@ygrek The feature is to be able to pass an OCaml module that is converted to the ts equivalent type or just have modularity to import types from another .atd file? |
atdts/src/lib/Codegen.ml
Outdated
| @@ -649,7 +649,7 @@ let get_ts_default (e : type_expr) (an : annot) : string option = | |||
| | None -> get_default_default e | |||
|
|
|||
| (* piggy-back on ocaml annotations TODO check ts ones first *) | |||
| let get_annot an field = Atd.Annot.get_opt_field ~parse:(fun s -> Some s) ~sections:["ocaml"] ~field an | |||
| let get_annot an field = Atd.Annot.get_opt_field ~parse:(fun s -> Some s) ~sections:["ts"] ~field an | |||
There was a problem hiding this comment.
this comment is now wrong
but also it is convenient to implement what this comment says - if there is no ts annot for from - use ocaml one. The reason this makes sense is because abstract without from gets generated as any in ts which is not very useful (I would consider actually turning it into error because from what i have seen 100% it is programmer mistake not intention)
There was a problem hiding this comment.
I disagree about reading <ocaml ...> annotations with atdts. TypeScript and OCaml should not know about each other. When there are similarities that are more or less universal, we should handle them in a language-neutral fashion (= no reference to other target languages).
See also #265 for a dedicated import syntax that turned out to be too complicated to implement in atdgen but is reasonable for the other target languages. The long-term solution I propose is to implement atdml (but unfortunately it would take me a solid 3 weeks to make something usable). See the comment I just left on my original PR attempt: #297 (comment)
|
|
||
| Position: left-hand side of a type definition, after the type name | ||
|
|
||
| Values: .ts file with exported types. This can be also seen as the |
There was a problem hiding this comment.
i believe this is documented in the general atd language documentation? (maybe mentioning in ts doc is useful but still should link/refer to the main doc)
There was a problem hiding this comment.
The annotation is <ts ...>, so it is specific to the TypeScript target and should be documented here.
CHANGES.md
Outdated
| @@ -3,6 +3,7 @@ Unreleased | |||
|
|
|||
| * atdgen: Add option `-j-gen-modules` to generate JSON generic submodules (#420) | |||
| * atd-parser: improve (syntax) error messages (#426) | |||
| * atdts: support <ocaml from...> annotation | |||
There was a problem hiding this comment.
This should be <ocaml ts=...>. I would add a slightly longer note explaining what the feature is about.
|
Thanks for the comments @mjambon @ygrek, I've cleaned up the code by removing the references to ocaml. Also rewired the build system so that we don't need a cleanup-for-dune to remove filesystem state have for dune work as expected. One thing that was surprising was that even though "ocaml" was not specified as a annot_schema in Lines 22 to 34 in 5d00b9b It looks like the annotation validation pass only tries to check if the section was defined in annot_schema and allows the rest through which seems wrong? I.e. if annot_schema contains |
| name of the original ATD file, without the ``.atd`` extension and | ||
| capitalized like an OCaml module name. | ||
|
|
||
| Semantics: specifies the base name of the OCaml modules where the type |
|
|
||
| .. code:: ocaml | ||
|
|
||
| type point_xy <ocaml from="Part1" t="point"> = abstract |
PR checklist
CHANGES.mdis up-to-date