Correct way of using "export" (duplicated symbols failure)

[Iván Zaera Avellón]

Hi again:

Given that if you use export from a library, the symbols are exported as if they were defined in the library that makes the export, if you do something like:

export "dart:async";

in one library you are implementing, you are likely to break everyone's code because as soon as some other person does the same and someone has to use both libraries it will get all "dart:async" symbols duplicated. That is noticed getting this error:

<<<

'file:///Users/Ivan/Documents/Dart/eldardo.org/zumolla_server/lib/src/server/api.dart': Error: line 11 pos 29: ambiguous reference: 'Completer' is defined in library 'dart:async' and also in 'file:///Users/Ivan/Documents/Dart/eldardo.org/zumolla_server/lib/controller.dart'

  Completer completer = new Completer();

>>>

Now, the questions are:

1) Do we have any recommendations on how to use export? For example: "only export libraries you implement".

2) Does all this makes sense? I mean: couldn't Dart just simply reexport the symbols in "dart:async" as if they had been in fact defined in "dart:async" and let them go down recursively? 

If we have no definite answers for 1 or 2, export is a very dangerous tool IMHO (at least for beginners).

[Iván Zaera Avellón]

Is this too difficult or too silly to answer?

Or is it that nobody wants to talk to me any more for asking these questions :'-(?

[Ladislav Thon]

Is this too difficult or too silly to answer?

Or is it that nobody wants to talk to me any more for asking these questions :'-(?

I don't think that this is the case :-)

Personally, I'd totally agree with export is a very dangerous tool (at least for beginners).

LT

[Iván Zaera Avellón]

Good to know I'm not talkin alone :-D

Anyone else? I personally don't see too much benefit in export considering the risks... Is it so useful?

--
Consider asking HOWTO questions at Stack Overflow: http://stackoverflow.com/tags/dart
 
 

[Vadim Tsushko]

    As I see it exprort is complementary to one class/one library approach. If you organize your package in that way (as opposed to one library with numbers of source files), you probably would not like press clients of your package import dozens libraries to make it work.

So in main library of your package you export all necessary inner libraries.

    I believe you right about external libraries - by all appearances they should be exported rarely if ever.

   

[Iván Zaera Avellón]

That makes sense.

I hadn't thought about one class/one lib approach because I usually use "part" to avoid having multiple files to be imported. I suppose having both methods is more flexible than just one.

2013/5/12 Vadim Tsushko <vadimt...@gmail.com>

    As I see it exprort is complementary to one class/one library approach. If you organize your package in that way (as opposed to one library with numbers of source files), you probably would not like press clients of your package import dozens libraries to make it work.

So in main library of your package you export all necessary inner libraries.

    I believe you right about external libraries - by all appearances they should be exported rarely if ever.

   

--
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
 
 

[Bob Nystrom]

On Fri, May 10, 2013 at 2:49 AM, Iván Zaera Avellón <iza...@gmail.com> wrote:

1) Do we have any recommendations on how to use export? For example: "only export libraries you implement".

2) Does all this makes sense? I mean: couldn't Dart just simply reexport the symbols in "dart:async" as if they had been in fact defined in "dart:async" and let them go down recursively? 

The language team has discussed this exact issue a few times. Their current belief, as I understand it, is that doing #2 would possibly lead to surprising behavior in some cases. I don't know the exact details, but every time it comes up, Gilad says it's asking for trouble.

The current behavior, while annoying in some cases, is at least quite simple and simplicity is the best feature.

For your specific case, I would definitely not export dart:async, or any other Dart core library. Those are frequently imported by users, so collisions are likely. 

If we have no definite answers for 1 or 2, export is a very dangerous tool IMHO (at least for beginners).

I don't use part, so I use export relatively frequently to break a program into separate libraries while still exposing a single library that users import. In this case though, I'm exporting something that I don't expect anyone to directly import so collisions should not occur.

A couple of things to keep in mind:

1. When a collision does occur, a user can avoid this by hiding the colliding names on one of their imports.

2. When you export, you can also use show/hide to only export a subset of a library's names.

Cheers!

- bob

[Iván Zaera Avellón]

This makes me think: using "part" in client applications is not very good, because you want small libs to optimize network load, but in server side it is different because there's no problem in composing a library with several parts.

Now, my doubt is: what would be best? Layout the server with many small libs or use parts?

2013/5/16 Bob Nystrom <rnys...@google.com>

[Gen]

I do not use "part of" either.
Instead:
- Each of my files is a library without "library" declaration.
- I use export to pack multiple library dependencies into a single library file.
- I use export to share and use my own libraries. Like using "part of".
- My import/export can become recursive. I am glad it works.

[Iván Zaera Avellón]

I use part to be able to do unittesting with privates visibility. That's the only reason.

My setup is: one public dart file with only the lib imports and the parts inclusion, and several parts. When I want to test that parts, I create a file in test with the same structure as the public dart file of the library and I can see all privates. If there was another way to do this, I would stop using part.

Example:

<<< server.dart (public file)

library server;

import whatever;

import whatever2;

part part1;

part part2;

>>>

<<< part1.dart

part of server;

class A {

  int _a;

}

>>>

<<< test/server_test.dart 

library server;

import whatever;

import whatever2;

part part1;

part part2;

main() {

  test where I can access A._a which makes me happy;

}

>>>

Maybe we should promote using import with small libs in the server and client and forget about part. If we could also have a way to see privates in tests (star this, please: https://code.google.com/p/dart/issues/detail?id=10219) that would make a lot of sense, IMHO.

Cheers,

Ivan

2013/5/17 Gen <gp78...@gmail.com>