Warning on importing two anonymous libraries seems noisy/unecessary

[sethladd]

Dart doesn't have a way to silence individual warning types. Perhaps if we had that ability, we wouldn't need this request. So maybe I should be filing a "allow someone to opt-out of certain warnings." :) In the meantime...

It is possible to import two anonymous/unnamed libraries into the same app. However, a developer will see a warning when this happens. Because the program starts, compiles, and runs just fine, the warning feels too oppressive/noisy.

This warning feels more like a hint or a lint rule, less like a "your program might break if you don't take care of this".

[gbracha]

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

[DartBot]

This comment was originally written by abarth@chromium.org

---

The context for this issue is that we have many small libraries in the sky framework. For example, each widget is its own library. We haven't been using |library| directives because it feels like boilerplate. Is there some bad thing that happens if we skip the |library| directives?

Here's a sampling of the libraries in question: https://github.com/domokit/mojo/tree/master/sky/framework/components

Thanks!

[bwilkerson]

The warning in question is specified in section 18.1:

It is a static warning to import two different libraries with the same name.

and in section 18.2:

It is a static warning to export two different libraries with the same name.

I can't find a definition of the word "different" in the specification, but the VM defines two libraries as being different if the URI's used to locate them are not equal. The Editor (or more accurately, the analysis engine) used to use a different definition, but now (as of 1.9) conforms to the VM because it's less confusing to users when all of the tools use the same definition.

[DartBot]

This comment was originally written by abarth@chromium.org

---

Yeah, I understand that it's part of the specification. I'm asking what bad thing will happen to me if I don't heed the warning.

If no bad thing that will happen, perhaps we should reconsider whether having the warning is a net gain or loss for Dart developers.

[DartBot]

This comment was originally written by @zoechi

---

A quick-fix in DartEditor to auto-generate a library statement from package name, path, and filename would be my preferred solution.

[DartBot]

This comment was originally written by abarth@chromium.org

---

If the warning about anonymous libraries isn't providing value, wouldn't it be better to remove the warning instead of using tooling to automate the process of adding the non-value-creating boilerplate?

[DartBot]

This comment was originally written by @zoechi

---

Sure, but I doubt it. If it doesn't provide any value it would be better to remove it from the language instead of just removing the warning.

[DartBot]

This comment was originally written by abarth@chromium.org

---

I can see the value in letting you name libraries and then warning you when you import the same named library twice with two different URLs because that's likely to be a mistake. It's harder for me to see the value in warning me about importing two anonymous libraries.

That's said, I'm open to having someone explain to me what bad thing will happen if I don't heed the warning.

[gbracha]

(1) The style of a single library per class is interesting. I wonder what the motivation for your current organization is? I can see that in such a situation, declaring your libraries seems like boilerplate. Usually, a library contains multiple classes and functions and is a bigger unit. It's a structuring device, but with one class per library, it is mainly overhead.

(2) The idea behind declaring libraries is no different than declaring anything else: classes, functions etc. Naming things is useful. The main scenario where you might want to name them today is reflection. If libraries could be extended, or parameterized, or passed around and stored, there would be more circumstances where you'd want to be able to refer to a library and hence name it. We'd like to lay the groundwork for that.

(3) So what bad thing will happen to you? Not much. Your situation is a weird special case. Anonymous libraries are designed as a quick and dirty way to get started coding, not as a mechanism to be used wholesale across a large code base. It's not something I would encourage. Now, given this special situation, you're suggesting for a special rule to accommodate your usage pattern.

Special cases are not something I like to introduce into a programming language. They undermine compositionality; I know that sounds abstract. Maybe this case is innocuous, but I've seen so many situations in language design where you get interactions no one ever foresaw or could plausibly foresee. You avoid these problems by making things uniform and clean, even when you can't see the harm in some special dispensation.

I am open to revisiting this, reluctantly. But I really want to understand why you use anonymous libraries on a large scale project.

[DartBot]

This comment was originally written by abarth@chromium.org

---

The style of a single library per class is interesting

The style isn't really a single library per class. The pattern is that each widget gets its own library. For example, Button is a widget, so its gets its own library. Some widgets have multiple classes. For example, the Drawer widget has an associated DrawerAnimation class, both of which are in the same library because they're intended to be used together.

For parts of the system that are more tightly coupled (i.e., can't be used a la carte), we have many classes in a single library. For example, https://github.com/domokit/mojo/blob/master/sky/framework/fn.dart has around a dozen classes.

I wonder what the motivation for your current organization is?

Originally we group many widgets together into larger libraries. For example, we had all the buttons (i.e., all the classes that subclassed ButtonBase) in one library. This caused a problem because it just so happened that all the subclasses of ButtonBase made use of an "_"-named property on ButtonBase, which meant that third-party developers writing new buttons couldn't create a button (i.e., a new subclass of ButtonBase in a different codebase) with the same fidelity that we could as part of the "button" library.

Of course, there are other ways of solving that problem. We could be careful about which "_"-named properties we accessed or introduce a linter, etc, but the most natural thing to do in Dart appeared to be to simply use separate libraries for each widget because then the Dart language itself would enforce the property that we wanted, namely that third-party developers could interact with the framework-provided widgets with exactly the same fidelity that framework-provided widgets could interact with each other.

It's a structuring device, but with one class per library, it is mainly overhead.

To be clear, we are using libraries as a device for structuring our code. For example, the fn.dart library is tightly coupled and therefore contains many classes. The framework widgets are intended to be loosely coupled, replaceable, and extendable therefore we use many libraries to reflect that loose structure.

Naming things is useful.

Indeed. One of Dart's strengths is that types are optional. If you'd like strict checking, you can use types to name things. If you're prefer to not have strict checking, you can omit the types and gain flexibility. I guess I had assumed that naming libraries followed a similar philosophy. If you name your library, you get to benefit from various checks in the analyzer. If you don't, then you get additional flexibility.

Your situation is a weird special case.

I guess it doesn't seem like that special a case. Presumably many people who write a component system and then want to provide a large number of loosely coupled, largely independent components will run into this same case. I've seen that use case recur in many project in many languages.

you're suggesting for a special rule to accommodate your usage pattern

My perspective is that this warning doesn't provide any value and therefore is spam. The warning for named libraries makes sense. If you import two libraries with the same name from two different URLs, it's likely that you've made a mistake. If you import two libraries that lack a name from two different URLs, it's unlikely you've made a mistake.

Now, you could take the position that you want people to name their libraries. In that case, perhaps the analyzer should issue a warning when it finds a library that lacks a name. That would seem more sensible that warning the consumer of the library if they just so happen to consume two libraries that lack names.

They undermine compositionality.

The current situation undermines compositionality. Suppose two people authors two separate libraries that lack names. They might well use these libraries in their own programs without ever triggering this warning because they don't happen to import a second unnamed library at the same time. Now, if a third person tries to compose these two libraries, that person will encounter this warning.

I really want to understand why you use anonymous libraries on a large scale project.

We're using both named and unnamed libraries in our project as seems appropriate in each case. The "well-known" or "central" libraries (e.g., fn.dart, sky.dart) have names. The collection of loosely coupled widgets are "spokes" and are implemented in small, self-contained, replaceable libraries that "plug in" to system and don't seem to need names.

[gbracha]

Thanks for the detailed response.

While I certainly think libraries should always be named, I lost that argument a long time ago. I admit I am reluctant to introduce a custom rule to make it easier for people to make massive use of anonymous libraries. Indeed, such a rule would then encourage people to use anonymous libs, as naming them could break clients (though two libs would have to be named the same for this to happen).

On the other hand, looking at the empty string as the analog of type dynamic might be a useful perspective as well. I'm not sure I buy it, but I am willing to think about it.

[sethladd]

See this patch that silences this warning for one particular toolchain: https://codereview.chromium.org/1135903003/

[DartBot]

This comment was originally written by ese...@chromium.org

---

Mojo has taken to ignoring this warning manually: http://crrev.com/1135903003

[johnmccutchan]

Sky now does the same: https://codereview.chromium.org/1142893007/