Add access to the isolate package-root/package-map in Platform.

sdk/lib/io/platform.dart

Index: sdk/lib/io/platform.dart
diff --git a/sdk/lib/io/platform.dart b/sdk/lib/io/platform.dart
index 56ddea0193b0df98b43e703e0c98828f4eb1e696..a365158b7fc54fda862cbc891e703a1a69e7036c 100644
--- a/sdk/lib/io/platform.dart
+++ b/sdk/lib/io/platform.dart
@@ -185,6 +185,29 @@ class Platform {
   static String get packageRoot => _Platform.packageRoot;
 
   /**
+   * Returns the package root of the current isolate, if any.
+   *
+   * If the isolate is using a [packageMap], this getter returns `null`,

[Ivan Posva, 2015/08/26 04:29:36]

This is not entirely correct: An isolate might not be using a packageMap and not
be using a packageRoot at the same time. For example when loaded from a
snapshot.

[Lasse Reichstein Nielsen, 2015/08/26 06:26:06]

Again, I'm trying to keep things simpler by saying that an isolate always use
one of the two options (with "nothing" being equivalent to an empty map).

+   * otherwise it returns the package root - a directory that package
+   * URIs are resolved against.

[nweiz, 2015/08/25 01:17:05]

It would be good to explicitly mention how this differs from [packageRoot].

[Lasse Reichstein Nielsen, 2015/08/25 06:23:00]

Acknowledged.

[Ivan Posva, 2015/08/26 04:29:36]

If we decide to remove packageRoot, then we do not need to document its
difference to the non-existing accessor.

[Lasse Reichstein Nielsen, 2015/08/26 06:26:06]

Acknowledged.

+   */
+  static Uri get packageRootUri => _Platform.packageRootUri;

[Ivan Posva, 2015/08/26 04:29:35]

All the new getters here need to return Futures. The package file resolution is
asynchronous and is only triggered on first access. In the case of launching
from a snapshot or when no packages are being loaded for the main entry point
(e.g. deferred loading) we will reach user code which can call these accessors
before their data has been resolved.
The lazy resolution of the packages location is mandatory to not negatively
impact launches which do not rely on packages to be loaded, which includes all
deployment scenarios from snapshots.

[Lasse Reichstein Nielsen, 2015/08/26 06:26:06]

Would it be possible to be blocking instead of async?

I wouldn't mind if he first access here blocked until the value was available.
The fact that the VM handles things lazily is an implementation detail that we
don't need to expose to users.

(I did notice some bug reports that looked like a lazy initialization being done
a little too late).

+
+  /**
+   * Returns the package mapping of the current isolate, if any.

[floitsch, 2015/08/24 15:09:45]

Should we mention that the package-mapping (as well as root) is the one that is
currently active. For compiled code it might differ from where the sources came
from?

(We need an "advanced" section in dartdocs).

[Lasse Reichstein Nielsen, 2015/08/25 06:23:00]

Acknowledged.

+   *
+   * If the current isolate is using [packageRoot], this getter returns `null`.

[nweiz, 2015/08/25 01:17:05]

Shouldn't this be [packageRootUri]? Presumably this will also be `null` if the
main isolate uses a package root because the implicit detection of .packages
failed, even if --package-root hasn't been passed.

[Lasse Reichstein Nielsen, 2015/08/25 06:23:00]

Good catch.
I'm not sure if a default package root for an HTTP base would not show up here.
I'll test that.

+   *
+   * The package map maps package names to a directory that package URIs for
+   * that package are resolved against, or to `null`, if the package name is

[floitsch, 2015/08/24 15:09:45]

no need to specify the `null` case. That's the normal behavior of maps.

[Lasse Reichstein Nielsen, 2015/08/25 06:23:00]

True. Should just say that it only has keys for a finite set of recognized
package names.

+   * not recognized.
+   *
+   * Returns an empty map if the isolate does not have a way to resolve package
+   * URIs.

[Ivan Posva, 2015/08/25 04:50:39]

Should return null if the isolate is not using a package map. Otherwise you
cannot distinguish between: Found a .packages file (or was passed an empty map
through the API) from package map not found/passed/

[Lasse Reichstein Nielsen, 2015/08/25 06:23:00]

I chose to do this instead because it's more useful.
This is not intended as a way to debug your package resolution detection, just 
to provide what is currently being used. 
I assumed that not having any resolution is indistinguishable from have an empty
map (no package name recognized), and it gives the user one less case to worry
about - one of the two getters always returns non-null.

[Ivan Posva, 2015/08/26 04:29:35]

Isn't that exactly what the null-aware operators would be for? If you don't care
about the fact that a neither a packageRoot or a packageMap are in use just do

var mapping = packageMap?[package_name];

[Lasse Reichstein Nielsen, 2015/08/26 06:26:06]

That would be an argument if ?[] was actually in the language. We only have a
half-baked null-aware specification where ?.foo works, but neither ?<operator>
nor ?(). I know it's harder to parse, but it's still feels like half a solution.

It's not just to make it easier to write - it's to make it easier to understand 
for the user (and therefore use correctly). If there are only two cases: use
package-root/use package-map, then it's impossible to forget he null case.

+   */
+  static Map<String, Uri> get packageMap => _Platform.packageMap;
+
+  /**
    * Returns the version of the current Dart runtime.
    *
    * The returned `String` is formatted as the