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

support private _main in Dart? #12460

Closed
sigmundch opened this issue Aug 14, 2013 · 2 comments
Closed

support private _main in Dart? #12460

sigmundch opened this issue Aug 14, 2013 · 2 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

@sigmundch
Copy link
Member

This bug is more a channel for discussion. I ran recently into this situation and it made me ponder things a bit.

I was wondering if there are any reasons why 'main' has to be public, or if it should actually be private (for example, suppose we call it '_main').

The rationale for this is that it would make it easy to write libraries that serve both as libraries and entrypoints, without having to hide their 'main' method.

For example:

 a.dart:
  library a;
  x = 1;
  _main() => print(x);

 b.dart:
  import 'a.dart';
  y = x + 1;
  _main() => print(y);

The idea is that these programs would have no conflicts in their imports and could be run as entrypoints ("dart a.dart" prints '1', "dart b.dart" prints '2').

This sounds like a minor improvement because you could write this with 'hide' directives today:
 a.dart:
  library a;
  x = 1;
  main() => print(x);

 b.dart:
  import 'a.dart' hide main;
  y = x + 1;
  main() => print(y);

But it brings up two questions:
 - what is more appropriate: a public or private method?
 - should we support this in the future?

@gbracha
Copy link
Contributor

gbracha commented Aug 21, 2013

My first instinct is that this is conceptually wrong. A private member is supposed to be used only from within the library. A private entry point is therefore an oxymoron. And yes, you can use hide - how hard is that? So I'd argue against this.


Set owner to @gbracha.
Added Accepted label.

@sigmundch sigmundch added Type-Enhancement area-language Dart language related items (some items might be better tracked at github.com/dart-lang/language). labels Aug 21, 2013
@kevmoo kevmoo added type-enhancement A request for a change that isn't a bug and removed priority-unassigned labels Feb 29, 2016
@munificent
Copy link
Member

Not a bad idea, but also probably not worth the effort. Given how ancient this request is, we seem to be able to live without it OK. :)

@munificent munificent added the closed-not-planned Closed as we don't intend to take action on the reported issue label Dec 16, 2016
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

4 participants