ChatGPT解决这个技术问题 Extra ChatGPT

When to use part/part of versus import/export in Dart?

I do not completely understand the difference between part/part of and import/export when using libraries in Dart. For example:

one.dart:
library one;
part "two.dart";
Class One {
};

and

two.dart:
part of one;
import 'somefile.dart';
Class Two {
}

versus

library one;
import 'two.dart';
Class One {
}

and

library two;
import 'somefile.dart';
export 'somefile.dart';
Class Two {
}

Both scenarios seem to do the same thing. When is it advantageous to use part and part of rather than import? And are there scenarios where import will not work, but part and part of will?


G
Günter Zöchbauer

update 2018/03

part and part of is used more and more for code generation scenarios recently (instead of deprecated transformers) and unlikely to go away anytime soon.

Packages like built_value, json_serializable, and many others depend on it.

Discouraged is only the patter where all files of a package are tied together to a single library by having one library file and all other files being part of that library.

original

In Dart, private members are accessible within the same library. With import you import a library and can access only its public members. With part/part of you can split one library into several files and private members are accessible for all code within these files.

see clarifications to below paragraph in above update

Using part / part of is discouraged and the Dart team is considering getting rid of it. I assume they will introduce something like "friend" (https://github.com/dart-lang/sdk/issues/22841), where two libraries can access each other's private members as an alternative before they discontinue part / part of (maybe in a future Dart version).


It's 2020, and they have kept part/part of. What do you think about the future?
There is an issue about supporting partial classes where I got the impression the Dart team plans to implement in the foreseeable future. That might depend on part. Otherwise, it's still useful for how code generation is used. Also the way private works in Dart it might be useful in some situations where a file grows too big, but couldn't otherwise be split because then code in one file couldn't access private stuff in the other files. With part it's easy to split anyway. Not a very common case though as far as I am aware of.
2021 and part/part of still there, stronger than ever. I don't see the point of the team to tell us to avoid using it if they don't induce changes in a timely manner. If they want to make radical changes it would definitely break a lot of Flutter apps and packages.
@AntoninGAVREL the Dart team (as in many other such projects) sometimes do a poor job in telling WHY something should be avoided when they say it should. part part of was very commonly used to treat the whole project as a single library with everything part of some lib/my_package.dart. And I think this is what they refer to when they discourage using part/part of. Their own code generator packages require part part of, so it's safe to assume that you are not doing anything wrong when you use it in such situations.
n
nbro

Let's suppose we have a Dart library called mylib, whose file is lib/mylib.dart.

library mylib;

// Definitions

That library can be included in the main.dart file as

import 'package:mypackage/mylib.dart';

When you create a new library and use other libraries you want to make available automatically when using your package, then you use export:

library mylib;

export 'otherlib.dart';

// Definitions

You can use the show keyword to import/export only some parts of a library (like a class or something).

You are using the part of directive wrong here. You can't use both library and part of, which is used to specify the contents that belong to a library. For example, you can split your library file in more than one file (the parts):

Suppose we have in the file mylib.dart:

library mylib;

part 'src/class1.part';
// More parts

And then we have in another file src/class1.part the part specified in mylib.dart

part of mylib;

class Class1 { 
  /* ... */
}

Thank you. The use of part of and library was just a typo, so I edited it out for future readability of the question.
@Robert I have a dilema between importing your own files (say a file with a class definition, services, etc) vs making them part of your library. I find that using import makes it pretty clear what the dependencies of each files are, but then you have keep adding imports every time you use something new, while part/part of just give you everything but then you don't know the dependencies. Also, your main library file then has all the dependencies. Then one thing I appreciate is creating top level function on the main library file. What do you think?
You can do it as you want :)
@Robert But there is a difference: All parts of a library have access to private members while shielding them from anything outside the library. In that sense they work more or less like Go packages or (this is a stretch) like splitted classes in C#. If you have a file with private and public members and only want the public ones to be exported then part of can be useful. Or if you really really need to shield some private members from the outer world. But most of the time the "don't touch src" convention solves that problem and is just good enough.
A
Argenti Apparatus

The Creating Library Packages article on the dartlang.org site recommends avoiding part / part of.

Note: You may have heard of the part directive, which allows you to split a library into multiple Dart files. We recommend that you avoid using part and create mini libraries instead.

The 'mini libraries' referred to are small library dart files in src which are imported into and exported from main libraries.


M
Mohamed Ali

using part/part of makes many files be treated as if they were one file

import/export doesn't, so this may be useful when private fields need to be accessed from another files (classes created on other files)


The simpler the better "makes many files be treated as if they were one file". I got it, thank you (I didn't with all the other answers)