export as

[xmine64]

I would like to be able to "export as" sources in libraries, to create something like namespaces.

src/foo/foo.dart:
class SomeClass { ... }

src/bar/bar.dart:
class SomeClass { ... }

src/lib.dart:
export 'foo/foo.dart' as foo;
export 'bar/bar.dart' as bar;

main.dart:
import 'src/lib.dart';

void main() {
    final a = foo.SomeClass();
    final b = bar.SomeClass();
}

[lrhn]

Sounds like you need general namespaces.

If you do import 'src/lib.dart' as prefix; you'd presumably have to write prefix.foo.SomeClass to access the class.

We've so far kept Dart library exports to a single un-nesting scope. The importer can then choose to put it into a single namespace (import prefix) or into the top-level import scope (no prefix).
That keeps us to either zero or one levels of namespace, not an arbitrary amount.

If exports can introduce "prefixes", aka namespaces, then we can presumably nest them arbitrarily
(export 'src/lib.dart' as baz; would mean you need baz.foo.SomeClass when importing).

At that point, we might as well introduce namespaces in general, as first class library members which can be exported, imported and nested.
Strawman:

namespace name {
  // declarations...
}

It gets tricky, because then we might also want a way to open a namespace inside another namespace. With arbitrary nesting comes the need for un-nesting. So some other library can choose to do:

import 'src/lib.dart';
open foo; // to export src/foo/foo.dart:SomeClass

or maybe

export 'src/lib.dart' show foo open foo;

or something (none of these are particularly well thought through).

We don't seem to have a request for nestable namespaces already (or I can't find it).

[xmine64]

If you do import 'src/lib.dart' as prefix; you'd presumably have to write prefix.foo.SomeClass to access the class.

Yeah I didn't think about that, but that comes to a possibility as well, but exporting a source with a prefix (or namespace) seems useful and essential to me, as I have models with same name but from different databases with different fields. Right now I'm doing something like this:

src/lib/foo.dart:
class FooSomeClass { ... }

src/lib/bar.dart:
class BarSomeClass { ... }

I could just use same name for both models and just put them in different namespaces, but it's just not possible. I can do this instead:

import 'package:mylib/src/lib/foo.dart' as foo;
import 'package:mylib/src/lib/bar.dart' as bar;

but it makes it hard to import a whole library with a lot of classes.

We don't seem to have a request for nestable namespaces already (or I can't find it).

It's not necessary to implement namespaces and nested namespaces, just extending "prefix" support is enough. Well I don't know much about dart compilers implementations, and it doesn't seem impossible to me to add a feature like this, but it can be tricky as you said. It may get possible to export sources with prefix in multiple levels and get a lot of namespaces inside other namespaces, but compiler can check for it and give an error when you use "import as" on a source with "export as" and use "export as" on a source with "export as".

[munificent]

No update. This doesn't seem to be something many users are clamoring for.

[CristovoXDGM]

any update?

[yokawaiik]

I think that it would be good features.

[babbage]

Being able to include a prefix at the point of exporting a library that would be required to use it would be useful to me.

[Lking03x]

Example

in lib/exports/route_imports.dart

export 'dart:io' show HttpStatus;
export 'package:dart_frog/dart_frog.dart';
export 'package:my_server/utils/database.dart';
export 'package:my_server/utils/validators.dart' as validators;
...

in lib/utils/validators.dart,
There would be top-level functions (not static members of a class 'validators' as one may need otherwise)
https://dart.dev/effective-dart/design#avoid-defining-a-class-that-contains-only-static-members

Then one would only have to import route_imports.dart for every endpoints that need it.

in routes/user/signup.dart

import 'package:my_server/exports/route_imports.dart';
...
    if (!(validators.email(json['email']!)  && validators.password(json['password']!))){
      return Response(
        body: ... ,
        statusCode: HttpStatus.badRequest,
        );
    }
    ...
...

Apart the obvious collisions problems, which is already well handled, It would be a great feature.

[vietstone-ng]

This will help organizing code and avoiding name collision between libs. Expect to have this.

[leadVisionary]

What is the recommended guidance for handling this now?

Like the op, I want to export two classes with the same name under different directories from my library (Java-style namespaces). Dart obviously complains if I add both in a top-level export.

Am I just supposed to encourage consumers to "violate my privates" and reach into lib/src?

[lrhn]

Currently you would have to rename one of the classes.

import "src/some/foo.dart" as some;
export "src/other/foo.dart"

typedef SomeFoo<T> = some.Foo<T>;

You cannot export two declarations with the same name from one library.

[leadVisionary]

It gets tricky, because then we might also want a way to open a namespace inside another namespace. With arbitrary nesting comes the need for un-nesting. So some other library can choose to do:

Respectfully disagree. Java kind of screwed the pooch in the beginning with packages not enforcing particularly strong boundaries, which led to a lot of messy OSGi and eventually the challenges of Jigsaw...but that challenge paid off. Modern (JDK17+) development with JPMS and the tooling to create minimized VM runtimes that include only the code you actually use is pretty spectacular.

From a matter of pure aesthetics, I find it a bit sad they have to add a module_info.java after adding a package_info.java before and add new keywords and syntax for things that probably could've been with annotations...but thinking deeper than "string prefix identifiers", toward what the attributes of an actually modularized system looks like, levels up the ecosystem as a whole.

Given that Dart's being developed in 2023, not 1994, one would think it could leverage some of the "battle experience" of successfully modularized ecosystems. Even Python says "Namespaces are one honking great idea—let’s do more of those!" so it seems odd for Dart to be developing so far without much support for them.

It would be cool to see this issue linked to a discussion on what modularity looks like for Dart moving forward.

[munificent]

Like the op, I want to export two classes with the same name under different directories from my library (Java-style namespaces). Dart obviously complains if I add both in a top-level export.

Rename one of the classes?

Am I just supposed to encourage consumers to "violate my privates" and reach into lib/src?

You can have multiple public libraries directly in lib.