[dart-misc] Proposal: Implicit library names and simplified import statement

[Gen]

Hi,

I would like to have implicit library names.
The file name without ".dart" file extension should be used as default
library name for anything in that file.

It would be nice to make the ".dart" file extension and the quotation marks
optional for import statements.
import "filePath";
import filePath;

[Günter Zöchbauer]

This is planned anyway AFAIK.

Post by Gen
Hi,
I would like to have implicit library names.
The file name without ".dart" file extension should be used as default library name for anything in that file.
It would be nice to make the ".dart" file extension and the quotation marks optional for import statements.
import "filePath";
import filePath;

[Kasper Peulen]

Yes, I hope this comes soon. I think I've seen a proposal for this a while
ago. Also this proposal talked about being able to write:

import test:test;

being the same as

import 'package:test/test.dart';

Post by Günter Zöchbauer
This is planned anyway AFAIK.

Post by Gen
Hi,
I would like to have implicit library names.
The file name without ".dart" file extension should be used as default

library name for anything in that file.

Post by Gen
It would be nice to make the ".dart" file extension and the quotation

marks optional for import statements.

Post by Gen
import "filePath";
import filePath;

--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

--
Kasper

['Bob Nystrom' via Dart Misc]

There are two things you're talking about here:

1. The name of the library.
2. The way you import the library.

Dart defines both of these concepts even though they have no relationship
to each other whatsoever.

The library's name is virtually useless. You have to come up with a unique
one in order to shut up an unhelpful warning about having two libraries
with the same name (the empty string). Fortunately, that warning is going
away in 1.13. After 1.13 comes out, I will be removing every single library
directive in my code. I encourage everyone else to do the same.(Unless you
use part. But then I encourage you to stop using that too.)

Once we all stop using library directives, that takes care of #1.

The next thing is that importing (and exporting, and parting) libraries is
needlessly verbose. My suggestion for that is in this bug
<https://github.com/dart-lang/sdk/issues/10018>, which Siggy turned into this
similar DEP
<https://github.com/sigmundch/DEP-nonuri-imports/blob/master/proposal.md>.

I've been focusing on other issues lately so this hasn't been a priority
for me, but I'd really like to improve this at some point.

– bob

Post by Kasper Peulen
Yes, I hope this comes soon. I think I've seen a proposal for this a while
import test:test;
being the same as
import 'package:test/test.dart';

Post by Günter Zöchbauer
This is planned anyway AFAIK.

Post by Gen
Hi,
I would like to have implicit library names.
The file name without ".dart" file extension should be used as default

library name for anything in that file.

Post by Gen
It would be nice to make the ".dart" file extension and the quotation

marks optional for import statements.

Post by Gen
import "filePath";
import filePath;

--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

--
Kasper
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

[Kasper Peulen]

@Bob Ah, good to hear that warnings goes away. How does this work? Is
starting form 1.13 the library automatically called the same as the
filename? Maybe it could then automatically name the library the same as
how you would import it (in the future with that DEP). So say I can in the
future write *import 'package:prompt/testing.dart'* with the following
syntax: *import prompt:testing*. Then I would expect that this library to
be called *prompt:testing.*

I guess the library name is still important for dartdocs.org. Also the
library name seems to be used in tooling:

[image: Inline image 1]

['Bob Nystrom' via Dart Misc]

Post by Kasper Peulen
@Bob Ah, good to hear that warnings goes away. How does this work? Is
starting form 1.13 the library automatically called the same as the
filename?

If I recall, a library without a library directive still has the same name
(an empty string). It's just that the language only says to warn on a name
collision if the name isn't "".

Post by Kasper Peulen
Maybe it could then automatically name the library the same as how you
would import it (in the future with that DEP).

A library doesn't know how it's imported. You could import it using a
number of different ways: relative URI, absolute, "package:", etc.

Post by Kasper Peulen
So say I can in the future write *import 'package:prompt/testing.dart'* with
the following syntax: *import prompt:testing*. Then I would expect that
this library to be called *prompt:testing.*
I guess the library name is still important for dartdocs.org. Also the

My guess is that we'll just tweak dartdoc and our tools to either not show
that or show something different there. Users don't really think about a
library's *name* anyway, what they think about is the URI they normally use
to import it. Tooling and dartdoc can probably guess at that. (For example,
dartdoc does know you're in a package, so it could identify the library by
it's package-relative path.)

– bob

[Gen]

Very nice :-)
I agree with everything in your posts.
And I did not know that omitting the "library" statement is already
possible. Nice again :-)

Post by 'Bob Nystrom' via Dart Misc

Post by Kasper Peulen
@Bob Ah, good to hear that warnings goes away. How does this work? Is
starting form 1.13 the library automatically called the same as the
filename?

If I recall, a library without a library directive still has the same name
(an empty string). It's just that the language only says to warn on a name
collision if the name isn't "".

Post by Kasper Peulen
Maybe it could then automatically name the library the same as how you
would import it (in the future with that DEP).

A library doesn't know how it's imported. You could import it using a
number of different ways: relative URI, absolute, "package:", etc.

Post by Kasper Peulen
So say I can in the future write *import 'package:prompt/testing.dart'* with
the following syntax: *import prompt:testing*. Then I would expect that
this library to be called *prompt:testing.*
I guess the library name is still important for dartdocs.org. Also the

My guess is that we'll just tweak dartdoc and our tools to either not show
that or show something different there. Users don't really think about a
library's *name* anyway, what they think about is the URI they normally
use to import it. Tooling and dartdoc can probably guess at that. (For
example, dartdoc does know you're in a package, so it could identify the
library by it's package-relative path.)
– bob

[Daniel Davidson]

What is the alternative to using parts? I thought they were a good way to
break up a library.

Post by 'Bob Nystrom' via Dart Misc
1. The name of the library.
2. The way you import the library.
Dart defines both of these concepts even though they have no relationship
to each other whatsoever.
The library's name is virtually useless. You have to come up with a unique
one in order to shut up an unhelpful warning about having two libraries
with the same name (the empty string). Fortunately, that warning is going
away in 1.13. After 1.13 comes out, I will be removing every single library
directive in my code. I encourage everyone else to do the same.(Unless you
use part. But then I encourage you to stop using that too.)
Once we all stop using library directives, that takes care of #1.
The next thing is that importing (and exporting, and parting) libraries is
needlessly verbose. My suggestion for that is in this bug
<https://github.com/dart-lang/sdk/issues/10018>, which Siggy turned into this
similar DEP
<https://github.com/sigmundch/DEP-nonuri-imports/blob/master/proposal.md>.
I've been focusing on other issues lately so this hasn't been a priority
for me, but I'd really like to improve this at some point.
– bob

Post by Kasper Peulen
Yes, I hope this comes soon. I think I've seen a proposal for this a
import test:test;
being the same as
import 'package:test/test.dart';

Post by Günter Zöchbauer
This is planned anyway AFAIK.

Post by Gen
Hi,
I would like to have implicit library names.
The file name without ".dart" file extension should be used as default

library name for anything in that file.

Post by Gen
It would be nice to make the ".dart" file extension and the quotation

marks optional for import statements.

Post by Gen
import "filePath";
import filePath;

--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to
http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send

--
Kasper
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

[Tyler James Thompson]

Wouldn't it be an issue importing a package named 'dart:server' or if
someone created a dart:io package? Wouldn't that override the default io
import? I'm sure the naming conventions say not to do this but it could
happen right? Or am I interpreting it wrong

Post by Daniel Davidson
What is the alternative to using parts? I thought they were a good way to
break up a library.

Post by 'Bob Nystrom' via Dart Misc
1. The name of the library.
2. The way you import the library.
Dart defines both of these concepts even though they have no relationship
to each other whatsoever.
The library's name is virtually useless. You have to come up with a
unique one in order to shut up an unhelpful warning about having two
libraries with the same name (the empty string). Fortunately, that warning
is going away in 1.13. After 1.13 comes out, I will be removing every
single library directive in my code. I encourage everyone else to do the
same.(Unless you use part. But then I encourage you to stop using that too.)
Once we all stop using library directives, that takes care of #1.
The next thing is that importing (and exporting, and parting) libraries
is needlessly verbose. My suggestion for that is in this bug
<https://github.com/dart-lang/sdk/issues/10018>, which Siggy turned into this
similar DEP
<https://github.com/sigmundch/DEP-nonuri-imports/blob/master/proposal.md>
.
I've been focusing on other issues lately so this hasn't been a priority
for me, but I'd really like to improve this at some point.
– bob

Post by Kasper Peulen
Yes, I hope this comes soon. I think I've seen a proposal for this a
import test:test;
being the same as
import 'package:test/test.dart';

Post by Günter Zöchbauer
This is planned anyway AFAIK.

Post by Gen
Hi,
I would like to have implicit library names.
The file name without ".dart" file extension should be used as

default library name for anything in that file.

Post by Gen
It would be nice to make the ".dart" file extension and the quotation

marks optional for import statements.

Post by Gen
import "filePath";
import filePath;

--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to
http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send

--
Kasper
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to
http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send

--

For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

[Gen]

AFAIU, packages can and should replace libraries.
E.g. import "package:myIO/WebSocket.dart"

And within a package, I see no need to have different libraries and library
parts either.

Post by Tyler James Thompson
Wouldn't it be an issue importing a package named 'dart:server' or if
someone created a dart:io package? Wouldn't that override the default io
import? I'm sure the naming conventions say not to do this but it could
happen right? Or am I interpreting it wrong

Post by Daniel Davidson
What is the alternative to using parts? I thought they were a good way to
break up a library.

Post by 'Bob Nystrom' via Dart Misc
1. The name of the library.
2. The way you import the library.
Dart defines both of these concepts even though they have no
relationship to each other whatsoever.
The library's name is virtually useless. You have to come up with a
unique one in order to shut up an unhelpful warning about having two
libraries with the same name (the empty string). Fortunately, that warning
is going away in 1.13. After 1.13 comes out, I will be removing every
single library directive in my code. I encourage everyone else to do the
same.(Unless you use part. But then I encourage you to stop using that too.)
Once we all stop using library directives, that takes care of #1.
The next thing is that importing (and exporting, and parting) libraries
is needlessly verbose. My suggestion for that is in this bug
<https://github.com/dart-lang/sdk/issues/10018>, which Siggy turned
into this similar DEP
<https://github.com/sigmundch/DEP-nonuri-imports/blob/master/proposal.md>
.
I've been focusing on other issues lately so this hasn't been a priority
for me, but I'd really like to improve this at some point.
– bob

Post by Kasper Peulen
Yes, I hope this comes soon. I think I've seen a proposal for this a
import test:test;
being the same as
import 'package:test/test.dart';

Post by Günter Zöchbauer
This is planned anyway AFAIK.

Post by Gen
Hi,
I would like to have implicit library names.
The file name without ".dart" file extension should be used as

default library name for anything in that file.

Post by Gen
It would be nice to make the ".dart" file extension and the

quotation marks optional for import statements.

Post by Gen
import "filePath";
import filePath;

--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to
http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send

--
Kasper
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to
http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send

--

For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

[Gen]

Although for large packages it might still be useful to have library names
that correspond implicitly the directory names like in Java.
E.g.
If in package MyPackage:
projectPath/lib/D/F.dart

Then the import statement becomes:
import "package:MyPackage/D/F.dart";
or better:
import MyPackage/D.F.Dart
or better:
import MyPackage.D.F.Dart

Post by Gen
AFAIU, packages can and should replace libraries.
E.g. import "package:myIO/WebSocket.dart"
And within a package, I see no need to have different libraries and
library parts either.

Post by Tyler James Thompson
Wouldn't it be an issue importing a package named 'dart:server' or if
someone created a dart:io package? Wouldn't that override the default io
import? I'm sure the naming conventions say not to do this but it could
happen right? Or am I interpreting it wrong

Post by Daniel Davidson
What is the alternative to using parts? I thought they were a good way
to break up a library.

Post by 'Bob Nystrom' via Dart Misc
1. The name of the library.
2. The way you import the library.
Dart defines both of these concepts even though they have no
relationship to each other whatsoever.
The library's name is virtually useless. You have to come up with a
unique one in order to shut up an unhelpful warning about having two
libraries with the same name (the empty string). Fortunately, that warning
is going away in 1.13. After 1.13 comes out, I will be removing every
single library directive in my code. I encourage everyone else to do the
same.(Unless you use part. But then I encourage you to stop using that too.)
Once we all stop using library directives, that takes care of #1.
The next thing is that importing (and exporting, and parting) libraries
is needlessly verbose. My suggestion for that is in this bug
<https://github.com/dart-lang/sdk/issues/10018>, which Siggy turned
into this similar DEP
<https://github.com/sigmundch/DEP-nonuri-imports/blob/master/proposal.md>
.
I've been focusing on other issues lately so this hasn't been a
priority for me, but I'd really like to improve this at some point.
– bob

Post by Kasper Peulen
Yes, I hope this comes soon. I think I've seen a proposal for this a
import test:test;
being the same as
import 'package:test/test.dart';

Post by Günter Zöchbauer
This is planned anyway AFAIK.

Post by Gen
Hi,
I would like to have implicit library names.
The file name without ".dart" file extension should be used as

default library name for anything in that file.

Post by Gen
It would be nice to make the ".dart" file extension and the

quotation marks optional for import statements.

Post by Gen
import "filePath";
import filePath;

--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to
http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it,

--
Kasper
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to
http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send

--

For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to
http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send

['Bob Nystrom' via Dart Misc]

Post by Daniel Davidson
What is the alternative to using parts? I thought they were a good way to
break up a library.

Exports.

Instead of:

*// my_big_library.dart*
library my_big_library;

import 'something_stuff_needs.dart';
import 'something_more_stuff_needs.dart';

part "stuff.dart";
part "more_stuff.dart";

*// stuff.dart*
part of my_big_library;

class Stuff { ... }

*// more_stuff.dart*
part of my_big_library;

var moreStuff = ...


Do:

*// my_big_library.dart*
export "stuff.dart";
export "more_stuff.dart";

*// stuff.dart*
import 'something_stuff_needs.dart';

class Stuff { ... }

*// more_stuff.dart*
import 'something_more_stuff_needs.dart';

var moreStuff = ...


If you have something private you want to share across these libraries,
move it to a separate library that all of the ones that share it import.

This gives you *much* better control over the namespaces in your code. You
can look at any file and see what names are in scope just by looking at
what it imports. You only share things between the sublibraries that need
to interact, and that sharing is explicit.

All of the Dart code I write is organized this way. If you want to see some
examples, look at pub <https://github.com/dart-lang/pub> or dart_style
<https://github.com/dart-lang/dart_style>.

Cheers!

– bob

[Günter Zöchbauer]

If the leftover that needs to share private members is still too big for
one file, you're out of luck.
Parts shouldn't go away until some friend relation can be established
between two libraries which allows to control what library can access
private members of another library..

Post by 'Bob Nystrom' via Dart Misc

Post by Daniel Davidson
What is the alternative to using parts? I thought they were a good way to
break up a library.

Exports.
*// my_big_library.dart*
library my_big_library;
import 'something_stuff_needs.dart';
import 'something_more_stuff_needs.dart';
part "stuff.dart";
part "more_stuff.dart";
*// stuff.dart*
part of my_big_library;
class Stuff { ... }
*// more_stuff.dart*
part of my_big_library;
var moreStuff = ...
*// my_big_library.dart*
export "stuff.dart";
export "more_stuff.dart";
*// stuff.dart*
import 'something_stuff_needs.dart';
class Stuff { ... }
*// more_stuff.dart*
import 'something_more_stuff_needs.dart';
var moreStuff = ...
If you have something private you want to share across these libraries,
move it to a separate library that all of the ones that share it import.
This gives you *much* better control over the namespaces in your code.
You can look at any file and see what names are in scope just by looking at
what it imports. You only share things between the sublibraries that need
to interact, and that sharing is explicit.
All of the Dart code I write is organized this way. If you want to see
some examples, look at pub <https://github.com/dart-lang/pub> or
dart_style <https://github.com/dart-lang/dart_style>.
Cheers!
– bob

[Jan Mostert]

I quite like the parts mechanism :-)

Post by Günter Zöchbauer
If the leftover that needs to share private members is still too big for
one file, you're out of luck.
Parts shouldn't go away until some friend relation can be established
between two libraries which allows to control what library can access
private members of another library..

Post by 'Bob Nystrom' via Dart Misc

Post by Daniel Davidson
What is the alternative to using parts? I thought they were a good way
to break up a library.

Exports.
*// my_big_library.dart*
library my_big_library;
import 'something_stuff_needs.dart';
import 'something_more_stuff_needs.dart';
part "stuff.dart";
part "more_stuff.dart";
*// stuff.dart*
part of my_big_library;
class Stuff { ... }
*// more_stuff.dart*
part of my_big_library;
var moreStuff = ...
*// my_big_library.dart*
export "stuff.dart";
export "more_stuff.dart";
*// stuff.dart*
import 'something_stuff_needs.dart';
class Stuff { ... }
*// more_stuff.dart*
import 'something_more_stuff_needs.dart';
var moreStuff = ...
If you have something private you want to share across these libraries,
move it to a separate library that all of the ones that share it import.
This gives you *much* better control over the namespaces in your code.
You can look at any file and see what names are in scope just by looking at
what it imports. You only share things between the sublibraries that need
to interact, and that sharing is explicit.
All of the Dart code I write is organized this way. If you want to see
some examples, look at pub <https://github.com/dart-lang/pub> or
dart_style <https://github.com/dart-lang/dart_style>.
Cheers!
– bob

--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

['Bob Nystrom' via Dart Misc]

Post by Günter Zöchbauer
If the leftover that needs to share private members is still too big for
one file, you're out of luck.
Parts shouldn't go away until some friend relation can be established
between two libraries which allows to control what library can access
private members of another library..

Nope. You can share "private" stuff just fine in most cases. Instead of:

*// my_lib.dart*
library my_lib;

part "a.dart";
part "b.dart";

var _sharedThing = ...

*// a.dart*
part of my_lib;

var stuff = _sharedThing;

*// b.dart*
part of my_lib;

var other = _sharedThing;


You move the stuff you want to share but not expose to a separate library
which isn't exported:

*// my_lib.dart*
export "a.dart";
export "b.dart";

*// shared.dart*
var sharedThing = ...

*// a.dart*
import "shared.dart";

var stuff = sharedThing;

*// b.dart*
import "shared.dart";

var other = sharedThing;


The *only* tricky case is if you want to have private instance methods of a
public class that are visible across the implementation libraries but not
to external users. There are patterns for that too, but they're a bit
cumbersome.

I've written piles of Dart code in the past few years—including several
packages you probably use every day—and I don't think I've used part since,
I don't know, 2012?

– bob

[Don Olmstead]

If you get rid of library names then how are you supposed to find things
through mirrors?

On Thu, Oct 22, 2015 at 10:48 AM, 'Bob Nystrom' via Dart Misc <

Post by 'Bob Nystrom' via Dart Misc

Post by Günter Zöchbauer
If the leftover that needs to share private members is still too big for
one file, you're out of luck.
Parts shouldn't go away until some friend relation can be established
between two libraries which allows to control what library can access
private members of another library..

*// my_lib.dart*
library my_lib;
part "a.dart";
part "b.dart";
var _sharedThing = ...
*// a.dart*
part of my_lib;
var stuff = _sharedThing;
*// b.dart*
part of my_lib;
var other = _sharedThing;
You move the stuff you want to share but not expose to a separate library
*// my_lib.dart*
export "a.dart";
export "b.dart";
*// shared.dart*
var sharedThing = ...
*// a.dart*
import "shared.dart";
var stuff = sharedThing;
*// b.dart*
import "shared.dart";
var other = sharedThing;
The *only* tricky case is if you want to have private instance methods of
a public class that are visible across the implementation libraries but not
to external users. There are patterns for that too, but they're a bit
cumbersome.
I've written piles of Dart code in the past few years—including several
packages you probably use every day—and I don't think I've used part
since, I don't know, 2012?
– bob
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

[Don Olmstead]

I think this has been brought up but with the part directive you could
probably do like C# and have a friend library,
https://msdn.microsoft.com/en-us/library/0tke9fxk.aspx, or maybe its just
implicit with the structure.

For the most part, no pun intended, I've been able to jettison part and do
a single class per library but with WebGL stuff I often want to control how
instances are created so part works there with internal constructors.

Post by Don Olmstead
If you get rid of library names then how are you supposed to find things
through mirrors?
On Thu, Oct 22, 2015 at 10:48 AM, 'Bob Nystrom' via Dart Misc <

Post by 'Bob Nystrom' via Dart Misc

Post by Günter Zöchbauer
If the leftover that needs to share private members is still too big for
one file, you're out of luck.
Parts shouldn't go away until some friend relation can be established
between two libraries which allows to control what library can access
private members of another library..

*// my_lib.dart*
library my_lib;
part "a.dart";
part "b.dart";
var _sharedThing = ...
*// a.dart*
part of my_lib;
var stuff = _sharedThing;
*// b.dart*
part of my_lib;
var other = _sharedThing;
You move the stuff you want to share but not expose to a separate library
*// my_lib.dart*
export "a.dart";
export "b.dart";
*// shared.dart*
var sharedThing = ...
*// a.dart*
import "shared.dart";
var stuff = sharedThing;
*// b.dart*
import "shared.dart";
var other = sharedThing;
The *only* tricky case is if you want to have private instance methods
of a public class that are visible across the implementation libraries but
not to external users. There are patterns for that too, but they're a bit
cumbersome.
I've written piles of Dart code in the past few years—including several
packages you probably use every day—and I don't think I've used part
since, I don't know, 2012?
– bob
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

['Bob Nystrom' via Dart Misc]

Post by Don Olmstead
If you get rid of library names then how are you supposed to find things
through mirrors?

https://api.dartlang.org/1.12.2/dart-mirrors/MirrorSystem/libraries.html

?

– bob

[Don Olmstead]

Didn't see that one. Typically ended up using
currentMirrorSystem().findLibrary(some_symbol)

On Thu, Oct 22, 2015 at 12:21 PM, 'Bob Nystrom' via Dart Misc <

Post by 'Bob Nystrom' via Dart Misc

Post by Don Olmstead
If you get rid of library names then how are you supposed to find things
through mirrors?

https://api.dartlang.org/1.12.2/dart-mirrors/MirrorSystem/libraries.html
?
– bob
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

[Don Olmstead]

Another question would be how would you annotate the library itself? What
does the documentation show?

I'm not opposed to the no library names think its just cause I'm so used to
writing library.

Post by Don Olmstead
Didn't see that one. Typically ended up using
currentMirrorSystem().findLibrary(some_symbol)
On Thu, Oct 22, 2015 at 12:21 PM, 'Bob Nystrom' via Dart Misc <

Post by 'Bob Nystrom' via Dart Misc

Post by Don Olmstead
If you get rid of library names then how are you supposed to find things
through mirrors?

https://api.dartlang.org/1.12.2/dart-mirrors/MirrorSystem/libraries.html
?
– bob
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an

['Bob Nystrom' via Dart Misc]

Post by Don Olmstead
Another question would be how would you annotate the library itself?

I think the test package just looks for the first metadata annotation that
appears in the library. <shrug>

We could say that if you want to provided a library-wide metadata
annotation then you should use a library tag. Kind of silly, but my main
goal is to get rid of the 99% of library tags that are utterly pointless.

Post by Don Olmstead
What does the documentation show?

Dartdoc, at least when I worked on it way back when, would just use the
first doc comment in the library. This seems like a pretty easy to fix
thing.

– bob

[Gen]

Actually, I would even like to have a system similar to Java.

If a file F is in directory D in the root directory for the compiler,
then the implicit library name in file F should be "D.F".