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

Require an import to choose server or client runtime #457

Closed
DartBot opened this issue Nov 15, 2011 · 4 comments
Closed

Require an import to choose server or client runtime #457

DartBot opened this issue Nov 15, 2011 · 4 comments
Assignees
Labels
area-language Dart language related items (some items might be better tracked at github.com/dart-lang/language). closed-not-planned Closed as we don't intend to take action on the reported issue type-enhancement A request for a change that isn't a bug

Comments

@DartBot
Copy link

DartBot commented Nov 15, 2011

This issue was originally filed by rice@google.com


  When writing code destined to run on a server, I can make use of runtime library classes such as File, InputStream, Process, etc. However, there is no marker in the code itself that indicates that the code is intended for that particular runtime (as opposed to a browser runtime). This makes it hard for tools such as the Dart editor to determine what library code to include when performing checks.

Currently, the editor complains about File, InputStream, etc., being missing. But even when the VM is integrated into the editor, if I am working on both client and serve code there will be no way for the editor to know which runtime library to use to validate a give source file.

I believe it would not be onerous for developers to add a single #import statement to the head of each library to bring in the appropriate runtime support for that library. Then tools will be able to make an appropriate determination of how to validate and run the code for each library.

@sgjesse
Copy link
Contributor

sgjesse commented Nov 15, 2011

cc @madsager.

@gbracha
Copy link
Contributor

gbracha commented Dec 14, 2011

The proposal is one way to deal with the issue. I tend to look at it differently: it's a configuration issue.


Set owner to @gbracha.
Removed Type-Defect label.
Added Type-Enhancement, Accepted labels.

@sgjesse
Copy link
Contributor

sgjesse commented Dec 14, 2011

Issue #796 has been merged into this issue.


cc @whesse.

@anders-sandholm
Copy link
Contributor

The future Package Manager should be helpful.


Added WontFix label.

This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-language Dart language related items (some items might be better tracked at github.com/dart-lang/language). closed-not-planned Closed as we don't intend to take action on the reported issue type-enhancement A request for a change that isn't a bug
Projects
None yet
Development

No branches or pull requests

5 participants