-
Notifications
You must be signed in to change notification settings - Fork 311
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
[Dart] Imports #2774
[Dart] Imports #2774
Conversation
type Assertion<'T> = | ||
interface end | ||
|
||
[<ImportAll("package:test/test.dart")>] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's pretty cool! I'm wondering if we can fork the dartdoc package to get the public api and generate bindings for any other package or even read the pubspec.yaml
and generate a file with bindings for all the current package dependencies.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for checking @Nhowka! I think that'd be great idea. I'm still learning Dart so if someone with more experience could have a look at forking dartdoc that'd be awesome.
Note that bindings for Dart will likely be slightly different than in JS. For JS we usually define an interface and then assign it to a value. In Dart it's not possible to assign a module to a value, so I assume we'll write the bindings usually as a static class with dummy member bodies (nativeOnly
) as in here. We've also discussed about doing the same in JS but there're already many bindings written with the "interface style".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we'll write the bindings usually as a static class with dummy member bodies (nativeOnly) as in here. We've also discussed about doing the same in JS but there're already many bindings written with the "interface style".
@alfonsogarciacaro
Can you give an example or point to the discussion, we're looking for the best representation of ad-hoc bindings for Rust too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As usual the discussion is scattered in different places, but I think there was a summary here: fable-compiler/fable-browser#77
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll take a shot on dartdoc, maybe generating a JSON representation with all the surface might be reusable on that side and we can consume it to generate our bindings.
Would it be feasible to attribute an entire module with an Import
? I'm wondering that because as Dart has top-level methods and fields besides the instance ones, so maybe we could leverage that to make a better 1:1 representation of the api. Also as Dart has no inner classes nor overloads, top level functions and values would be the static top-level methods and fields, and types and/or interfaces would represent the classes. For the generated file, the import could also have the same name as the module, like
[<Import("package:some_package/some_file.dart")>]
module SomeFile = ...
turning into
import "package:some_package/some_file.dart" as SomeFile;
Dart is kinda quirky as every class is also an interface that can be implemented, it can be somewhat useful but I'm not sure how we could or even should represent that... Named constructors and factories could probably be encoded as static methods returning the class without any issues.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
08d875b
to
5da9bb7
Compare
5da9bb7
to
3d344f1
Compare
First support for imports in Dart and add a few more binary expression tests.
@dbrattli @ncave In this PR I'm also trying to unify the code to decide the extension of the generated files based on the language. I realized we had two methods to change extensions, the
ChangeExtension
polyfill andreplaceExtension
with slightly different behavior so I've removed the latter for simplicity. I've also made more explicit (changeExtensionButUseDefaultExtensionInFableModules
) a mild hack I added when transitioning to Fable 3: files compiled withinfable_modules
would always use.fs.js
extension, because in some packages they can conflict with native .js files. I've restricted the hack now to JS as we should avoid this practice in other languages and always use different names for the files regardless of the extension.