add sendRequest to VMIsolateRef

lib/src/isolate.dart

 // Copyright (c) 2015, the Dart project authors.  Please see the AUTHORS file
 // for details. All rights reserved. Use of this source code is governed by a
 // BSD-style license that can be found in the LICENSE file.
 
 import 'dart:async';
 import 'dart:collection';
 
 import 'package:async/async.dart';
 import 'package:crypto/crypto.dart';
 import 'package:json_rpc_2/json_rpc_2.dart' as rpc;
@@ skipping 246 matching lines @@
       var response = await _scope.sendRequest(
           "addBreakpointWithScriptUri", params);
       return newVMBreakpoint(_scope, response);
     } on rpc.RpcException catch (error) {
       // Error 102 indicates that the breakpoint couldn't be created.
       if (error.code == 102) return null;
       rethrow;
     }
   }
 
+  /// Makes a raw RPC to a VM service extension registered in the isolate
+  /// corresponding to the ID [number].

[nweiz, 2016/02/10 22:17:11]

"the isolate ..." -> "this isolate."

+  ///
+  /// [method] must correspond to a VM service extension installed on the VM
+  /// isolate and it must begin with prefix "ext.".

[nweiz, 2016/02/10 21:28:28]

It sort of feels like this should just automatically add "ext." rather than
complaining that the user didn't do so manually. If you think that's too
confusing, though, I could be convinced.

[yjbanov, 2016/02/10 22:06:06]

I think there's value in having `invokeExtension` and `registerExtension` match
each other. Also, I expect people will want to store method names as constants
in shared libraries. They'll have to declare more constants if the names do not
match.

[nweiz, 2016/02/10 22:17:11]

SGTM

+  ///
+  /// [params] are passed to the extension handler and must be serializable to
+  /// a JSON string.
+  Future<Map> invokeExtension(String method, [Map<String, Object> params]) {

[nweiz, 2016/02/10 21:28:28]

Based on the ServiceExtensionHandler API, I think this signature should be
Future<String> invokeExtension(String method, [Map<String, String> params]).

[yjbanov, 2016/02/10 22:06:06]

I thought so too initially, but turns out the JSON RPC front-end accepts
non-strings, but encodes the values to strings prior to passing to the extension
callback. Again, I'm all for matching signatures, as that's what users see and
there's no loss of generality that I can think of.

Your call.

[nweiz, 2016/02/10 22:17:11]

I think we should only allow strings here. We definitely don't want people
thinking they can transparently pass through map values and stuff like that.

Given that the protocol effectively JSON-decodes the response, it seems like
this should be a Future<Object> rather than a Future<Map>.

+    if (!method.startsWith('ext.')) {
+      throw new ArgumentError('Extension method names must begin with "ext." prefix: ${method}');

[nweiz, 2016/02/10 21:28:28]

Long line.

Also, you can make this a little more semantic using ArgumentError.value:
https://api.dartlang.org/1.14.1/dart-core/ArgumentError/ArgumentError.value.html

[yjbanov, 2016/02/10 22:06:06]

Done.

+    }
+    return _scope.sendRequest(method, params);
+  }
+
   bool operator ==(other) => other is VMIsolateRef &&
       other._scope.isolateId == _scope.isolateId;
 
   int get hashCode => _scope.isolateId.hashCode;
 
   String toString() => name;
 }
 
 /// A full isolate on the remote VM.
 class VMIsolate extends VMIsolateRef {
@@ skipping 81 matching lines @@
 
   /// The isolate continues until it exits the current function.
   static const out = const VMStep._("Out");
 
   /// The string name of the step type.
   final String _value;
 
   const VMStep._(this._value);
 
   String toString() => _value;
-}
+}