Initial commit for Chrome.* APIs in Dart

Initial commit for Chrome.* APIs in Dart

Added the initial wrappings for the Chrome.* APIs that use the JS() function. Only chrome.app.window and chrome.app.runtime are wrapped for now.

Also added "dart:chrome" to the compiler's list of libraries allowed to use convertDartClosureToJS(), and other internal library functions.

Committed: https://code.google.com/p/dart/source/detail?r=17743

[blois, 2013-01-23 02:06:12]

Some quick comments before I head out to give you something to start on!

https://codereview.chromium.org/12049030/diff/1/sdk/lib/_internal/compiler/im...
File sdk/lib/_internal/compiler/implementation/compiler.dart (right):

https://codereview.chromium.org/12049030/diff/1/sdk/lib/_internal/compiler/im...
sdk/lib/_internal/compiler/implementation/compiler.dart:606: || libraryName ==
'dart:chrome'
Probably want to break this out into a separate CL.

https://codereview.chromium.org/12049030/diff/1/tools/dom/src/chrome/_utils.dart
File tools/dom/src/chrome/_utils.dart (right):

https://codereview.chromium.org/12049030/diff/1/tools/dom/src/chrome/_utils.d...
tools/dom/src/chrome/_utils.dart:1: // Copyright (c) 2012, the Dart project
authors.  Please see the AUTHORS file
2013

https://codereview.chromium.org/12049030/diff/1/tools/dom/src/chrome/_utils.d...
tools/dom/src/chrome/_utils.dart:3: // BSD-style license that can be found in
the LICENSE file.
Normally we don't use leading _ for file names (at least I believe not).

Also- should these types have leading underscores? Right now they are publicly
accessible. Seems a bit misleading from the file name.

Also- 'utils' is one of those names that if you're using it, it's most likely
wrong :)

https://codereview.chromium.org/12049030/diff/1/tools/dom/src/chrome/_utils.d...
tools/dom/src/chrome/_utils.dart:200: JS('void', '#.conditions = #',
this._jsObject, convertArgument(conditions));
line length

https://codereview.chromium.org/12049030/diff/1/tools/dom/src/chrome/_utils.d...
tools/dom/src/chrome/_utils.dart:239: *  class $Event_ChromeAppRuntimeOnLaunched
extends $Event {
For DOM events, we're moving them over to streams. Not sure how well they'd work
with this API, but would be good to investigate in the future.

https://codereview.chromium.org/12049030/diff/1/tools/dom/src/chrome/_utils.d...
tools/dom/src/chrome/_utils.dart:254: class $Event {
Why the leading $?

https://codereview.chromium.org/12049030/diff/1/tools/dom/src/chrome/_utils.d...
tools/dom/src/chrome/_utils.dart:308: * @param eventName Name of the event this
function affects.
Dart doesn't use JS-style param comments.

https://codereview.chromium.org/12049030/diff/1/tools/dom/src/chrome/_utils.d...
tools/dom/src/chrome/_utils.dart:312: void addRules(String eventName, List<Rule>
rules, [ void callback(List<Rule> rules) ]) {
Usually no space between [ and arg-

rules, [void callback...)]) {

https://codereview.chromium.org/12049030/diff/1/tools/dom/src/chrome/_utils.d...
tools/dom/src/chrome/_utils.dart:312: void addRules(String eventName, List<Rule>
rules, [ void callback(List<Rule> rules) ]) {
80 char line length (and more below)

https://codereview.chromium.org/12049030/diff/1/tools/dom/src/chrome/app.runt...
File tools/dom/src/chrome/app.runtime.dart (right):

https://codereview.chromium.org/12049030/diff/1/tools/dom/src/chrome/app.runt...
tools/dom/src/chrome/app.runtime.dart:33: String action,
Normally these are all collapsed onto the same line (I know, I like the expanded
syntax for longer lists, but it's convention).

https://codereview.chromium.org/12049030/diff/1/tools/dom/src/chrome/app.runt...
tools/dom/src/chrome/app.runtime.dart:37: Function postFailure
Can this be further typed? As in what are the parameter values?

https://codereview.chromium.org/12049030/diff/1/tools/dom/src/chrome/app.runt...
tools/dom/src/chrome/app.runtime.dart:68: String get action {
Couldn't you just have it always have the JS proxy, then convert values when
getting/setting? Might minimize the complexity of this.

https://codereview.chromium.org/12049030/diff/1/tools/dom/src/chrome/chrome.dart
File tools/dom/src/chrome/chrome.dart (right):

https://codereview.chromium.org/12049030/diff/1/tools/dom/src/chrome/chrome.d...
tools/dom/src/chrome/chrome.dart:67: final $API_Chrome chrome = new
$API_Chrome();
I think the preference is that the members of chrome just become library members
and this type is removed.

Then when using it you import 'dart:chrome' as 'chrome';

[sashab, 2013-01-23 04:45:34]

Some changes due to feedback, mainly:

- Moved compiler change to its own issue
(https://codereview.chromium.org/12051031)
- Changed all Chrome Dart types to have backing JS objects, even user-created
ones
- Various formatting & style fixes

https://codereview.chromium.org/12049030/diff/1/sdk/lib/_internal/compiler/im...
File sdk/lib/_internal/compiler/implementation/compiler.dart (right):

https://codereview.chromium.org/12049030/diff/1/sdk/lib/_internal/compiler/im...
sdk/lib/_internal/compiler/implementation/compiler.dart:606: || libraryName ==
'dart:chrome'
On 2013/01/23 02:06:12, blois wrote:
> Probably want to break this out into a separate CL.

Done: https://codereview.chromium.org/12051031

https://codereview.chromium.org/12049030/diff/1/tools/dom/src/chrome/_utils.dart
File tools/dom/src/chrome/_utils.dart (right):

https://codereview.chromium.org/12049030/diff/1/tools/dom/src/chrome/_utils.d...
tools/dom/src/chrome/_utils.dart:1: // Copyright (c) 2012, the Dart project
authors.  Please see the AUTHORS file
On 2013/01/23 02:06:12, blois wrote:
> 2013

Done.

https://codereview.chromium.org/12049030/diff/1/tools/dom/src/chrome/_utils.d...
tools/dom/src/chrome/_utils.dart:3: // BSD-style license that can be found in
the LICENSE file.
On 2013/01/23 02:06:12, blois wrote:
> Normally we don't use leading _ for file names (at least I believe not).
No worries; I can fix this.

> 
> Also- should these types have leading underscores? Right now they are publicly
> accessible. Seems a bit misleading from the file name.
Again, I'll remove the _ from the file name.

> 
> Also- 'utils' is one of those names that if you're using it, it's most likely
> wrong :)
> 
What should it be called? Should Events and ChromeObject be in their own files?
Or maybe it should all be in chrome.dart?

https://codereview.chromium.org/12049030/diff/1/tools/dom/src/chrome/_utils.d...
tools/dom/src/chrome/_utils.dart:200: JS('void', '#.conditions = #',
this._jsObject, convertArgument(conditions));
On 2013/01/23 02:06:12, blois wrote:
> line length
Done, except for the comments on Events

https://codereview.chromium.org/12049030/diff/1/tools/dom/src/chrome/_utils.d...
tools/dom/src/chrome/_utils.dart:239: *  class $Event_ChromeAppRuntimeOnLaunched
extends $Event {
On 2013/01/23 02:06:12, blois wrote:
> For DOM events, we're moving them over to streams. Not sure how well they'd
work
> with this API, but would be good to investigate in the future.
We could change these to be streams later? Are these events even comparable to
DOM events in their implementation (ie would we ever want them to be
interchangeable/subclasses of the same parent type)?

https://codereview.chromium.org/12049030/diff/1/tools/dom/src/chrome/_utils.d...
tools/dom/src/chrome/_utils.dart:254: class $Event {
On 2013/01/23 02:06:12, blois wrote:
> Why the leading $?
To distinguish it from html:Event. Should I just call it Event?

https://codereview.chromium.org/12049030/diff/1/tools/dom/src/chrome/_utils.d...
tools/dom/src/chrome/_utils.dart:308: * @param eventName Name of the event this
function affects.
On 2013/01/23 02:06:12, blois wrote:
> Dart doesn't use JS-style param comments.
These were taken from events.idl. Should I just rewrite them? This part of the
file will not be automatically generated.

https://codereview.chromium.org/12049030/diff/1/tools/dom/src/chrome/_utils.d...
tools/dom/src/chrome/_utils.dart:312: void addRules(String eventName, List<Rule>
rules, [ void callback(List<Rule> rules) ]) {
On 2013/01/23 02:06:12, blois wrote:
> Usually no space between [ and arg-
> 
> rules, [void callback...)]) {

Done.

https://codereview.chromium.org/12049030/diff/1/tools/dom/src/chrome/_utils.d...
tools/dom/src/chrome/_utils.dart:312: void addRules(String eventName, List<Rule>
rules, [ void callback(List<Rule> rules) ]) {
On 2013/01/23 02:06:12, blois wrote:
> 80 char line length (and more below)

Done (except for Event comments).

https://codereview.chromium.org/12049030/diff/1/tools/dom/src/chrome/app.runt...
File tools/dom/src/chrome/app.runtime.dart (right):

https://codereview.chromium.org/12049030/diff/1/tools/dom/src/chrome/app.runt...
tools/dom/src/chrome/app.runtime.dart:33: String action,
On 2013/01/23 02:06:12, blois wrote:
> Normally these are all collapsed onto the same line (I know, I like the
expanded
> syntax for longer lists, but it's convention).

Done.

https://codereview.chromium.org/12049030/diff/1/tools/dom/src/chrome/app.runt...
tools/dom/src/chrome/app.runtime.dart:37: Function postFailure
On 2013/01/23 02:06:12, blois wrote:
> Can this be further typed? As in what are the parameter values?

This is actually a mistake; see the TODO below:
  TODO(sashab): What is a NullCallback() type? Add postResult and postFailure
once understanding what this type is

https://codereview.chromium.org/12049030/diff/1/tools/dom/src/chrome/app.runt...
tools/dom/src/chrome/app.runtime.dart:68: String get action {
On 2013/01/23 02:06:12, blois wrote:
> Couldn't you just have it always have the JS proxy, then convert values when
> getting/setting? Might minimize the complexity of this.

Done.

https://codereview.chromium.org/12049030/diff/1/tools/dom/src/chrome/chrome.dart
File tools/dom/src/chrome/chrome.dart (right):

https://codereview.chromium.org/12049030/diff/1/tools/dom/src/chrome/chrome.d...
tools/dom/src/chrome/chrome.dart:67: final $API_Chrome chrome = new
$API_Chrome();
On 2013/01/23 02:06:12, blois wrote:
> I think the preference is that the members of chrome just become library
members
> and this type is removed.
> 
> Then when using it you import 'dart:chrome' as 'chrome';

The reason I didn't want to do this is because there are still types in chrome
(return types, parameters to functions, etc) that I don't want prefixed with the
chrome. extension. To avoid confusing these with the _actual_ APIs, I would
rather leave the APIs prefixed with chrome.

e.g.

import 'dart:chrome';

void main() {
  chrome.app.runtime.onLaunched.addListener((LaunchData launchData) {
    chrome.app.window.create('chrome_app.html',
        new CreateWindowOptions(width: 800, height: 600));
  });
}

rather than:

import 'dart:chrome' as chrome;

void main() {
  chrome.app.runtime.onLaunched.addListener((chrome.LaunchData launchData) {
    chrome.app.window.create('chrome_app.html',
        new chrome.CreateWindowOptions(width: 800, height: 600));
  });
}

[Emily Fortuna, 2013-01-23 19:28:04]

another pass through for dart-ification recommendations.

https://codereview.chromium.org/12049030/diff/1/tools/dom/src/chrome/_utils.dart
File tools/dom/src/chrome/_utils.dart (right):

https://codereview.chromium.org/12049030/diff/1/tools/dom/src/chrome/_utils.d...
tools/dom/src/chrome/_utils.dart:254: class $Event {
On 2013/01/23 04:45:34, sasha_b wrote:
> On 2013/01/23 02:06:12, blois wrote:
> > Why the leading $?
> To distinguish it from html:Event. Should I just call it Event?

I made a comment on this in another version of this file. Yeah, $Event is
unusual for Dart. If someone wants to distinguish between the two, they can
import one library with a prefix: 
"#import foo.dart as foo;"

https://codereview.chromium.org/12049030/diff/6008/sdk/lib/chrome/dart2js/chr...
File sdk/lib/chrome/dart2js/chrome_dart2js.dart (right):

https://codereview.chromium.org/12049030/diff/6008/sdk/lib/chrome/dart2js/chr...
sdk/lib/chrome/dart2js/chrome_dart2js.dart:266: * @param eventName Name of the
event this function affects.
FYI: Use markdown syntax for documentation
http://daringfireball.net/projects/markdown/syntax [eventName], and it doesn't
need to be in its own sentence. The documentation is intended to be more natural
like a comment.

https://codereview.chromium.org/12049030/diff/6008/sdk/lib/chrome/dart2js/chr...
sdk/lib/chrome/dart2js/chrome_dart2js.dart:350: class $API_ChromeApp {
any reason why you're using the $ to start all of these classes? That's
something our JavaScript compiler does to its generated code, but I've not seen
us do it with our Dart code itself.

https://codereview.chromium.org/12049030/diff/6008/tools/dom/src/chrome/app.r...
File tools/dom/src/chrome/app.runtime.dart (right):

https://codereview.chromium.org/12049030/diff/6008/tools/dom/src/chrome/app.r...
tools/dom/src/chrome/app.runtime.dart:17: Intent({String action, String type,
var data}) {
90% sure this constructor can be simplified to:

Intent({this.action, this.type, this.data});

here and below.

https://codereview.chromium.org/12049030/diff/6008/tools/dom/src/chrome/app.r...
tools/dom/src/chrome/app.runtime.dart:34: String get action =>
when you have a getter with the => syntax, (and it's short), go ahead and make
it all one line.

https://codereview.chromium.org/12049030/diff/6008/tools/dom/src/chrome/app.r...
tools/dom/src/chrome/app.runtime.dart:110: LaunchData._proxy(_jsObject)
same with this -- dart common style has all of this on one line.

https://codereview.chromium.org/12049030/diff/6008/tools/dom/src/chrome/app.r...
tools/dom/src/chrome/app.runtime.dart:215: => super.addListener(callback);
if you must separate a => function onto two lines, put the "=>" on the first
line.

https://codereview.chromium.org/12049030/diff/6008/tools/dom/src/chrome/app.r...
tools/dom/src/chrome/app.runtime.dart:247: JS('void', '#.postIntentResponse(#)',
this._jsObject, convertArgument(intentResponse));
80 char or less, please. :-)

here and below

https://codereview.chromium.org/12049030/diff/6008/tools/dom/src/chrome/app.w...
File tools/dom/src/chrome/app.window.dart (right):

https://codereview.chromium.org/12049030/diff/6008/tools/dom/src/chrome/app.w...
tools/dom/src/chrome/app.window.dart:333: // called on a handle to a script
context for another page, for example:
if you make this comment triple slash, it will be be considered documentation,
and run through our doc generator. Also, dart comments follow approximately the
markdown syntax http://daringfireball.net/projects/markdown/syntax, so use
[AppWindow] (in this case we auto-link if it's already defined in the same
class).

https://codereview.chromium.org/12049030/diff/6008/tools/dom/src/chrome/utils...
File tools/dom/src/chrome/utils.dart (right):

https://codereview.chromium.org/12049030/diff/6008/tools/dom/src/chrome/utils...
tools/dom/src/chrome/utils.dart:314: * @param ruleIdentifiers If an array is
passed, only rules with identifiers contained in this array are unregistered.
80 char....

[vsm, 2013-01-23 20:44:50]

Nice start!  A few more comments....

https://chromiumcodereview.appspot.com/12049030/diff/6008/tools/dom/src/chrom...
File tools/dom/src/chrome/app.runtime.dart (right):

https://chromiumcodereview.appspot.com/12049030/diff/6008/tools/dom/src/chrom...
tools/dom/src/chrome/app.runtime.dart:12: // A WebIntents intent object.
Deprecated.
If this is already deprecated in JS, why generate a Dart API?

https://chromiumcodereview.appspot.com/12049030/diff/6008/tools/dom/src/chrom...
File tools/dom/src/chrome/chrome.dart (right):

https://chromiumcodereview.appspot.com/12049030/diff/6008/tools/dom/src/chrom...
tools/dom/src/chrome/chrome.dart:11: class $API_ChromeApp {
Why the "$API_"?

https://chromiumcodereview.appspot.com/12049030/diff/6008/tools/dom/src/chrom...
File tools/dom/src/chrome/utils.dart (right):

https://chromiumcodereview.appspot.com/12049030/diff/6008/tools/dom/src/chrom...
tools/dom/src/chrome/utils.dart:55: }
I'm not sure it's worth having these helper methods as opposed to just calling
JS directly.  In this case, in particular, the type of value is likely known at
the call site and you can avoid the generic convertArgument call.

[sashab, 2013-01-23 22:24:53]

Fixed some styling issues.

- Is it worth getting rid of getMember() and setMember()?
- What should I call utils.dart?
- What should I call the API_ and Event_ classes?

https://codereview.chromium.org/12049030/diff/1/tools/dom/src/chrome/_utils.dart
File tools/dom/src/chrome/_utils.dart (right):

https://codereview.chromium.org/12049030/diff/1/tools/dom/src/chrome/_utils.d...
tools/dom/src/chrome/_utils.dart:254: class $Event {
On 2013/01/23 19:28:04, Emily Fortuna wrote:
> On 2013/01/23 04:45:34, sasha_b wrote:
> > On 2013/01/23 02:06:12, blois wrote:
> > > Why the leading $?
> > To distinguish it from html:Event. Should I just call it Event?
> 
> I made a comment on this in another version of this file. Yeah, $Event is
> unusual for Dart. If someone wants to distinguish between the two, they can
> import one library with a prefix: 
> "#import foo.dart as foo;"

I guess I'm just worried because I'm importing dart:html in this library. Will
Event be overwritten correctly for all files? I don't want to use "import
dart:html as html", as JS() doesn't seem to resolve namespaces correctly (ie it
gets confused when I enter "html.Window" as the type)

https://codereview.chromium.org/12049030/diff/6008/sdk/lib/chrome/dart2js/chr...
File sdk/lib/chrome/dart2js/chrome_dart2js.dart (right):

https://codereview.chromium.org/12049030/diff/6008/sdk/lib/chrome/dart2js/chr...
sdk/lib/chrome/dart2js/chrome_dart2js.dart:266: * @param eventName Name of the
event this function affects.
On 2013/01/23 19:28:04, Emily Fortuna wrote:
> FYI: Use markdown syntax for documentation
> http://daringfireball.net/projects/markdown/syntax [eventName], and it doesn't
> need to be in its own sentence. The documentation is intended to be more
natural
> like a comment.

Done.

https://codereview.chromium.org/12049030/diff/6008/sdk/lib/chrome/dart2js/chr...
sdk/lib/chrome/dart2js/chrome_dart2js.dart:350: class $API_ChromeApp {
On 2013/01/23 19:28:04, Emily Fortuna wrote:
> any reason why you're using the $ to start all of these classes? That's
> something our JavaScript compiler does to its generated code, but I've not
seen
> us do it with our Dart code itself.

I need to distinguish, for example:
  chrome.app.window
from:
  AppWindow

chrome.app.window is the API's AppWindow, whereas AppWindow is an actual type.

I'm not sure on the best naming convention. Maybe APIAppWindow?

https://codereview.chromium.org/12049030/diff/6008/tools/dom/src/chrome/app.r...
File tools/dom/src/chrome/app.runtime.dart (right):

https://codereview.chromium.org/12049030/diff/6008/tools/dom/src/chrome/app.r...
tools/dom/src/chrome/app.runtime.dart:12: // A WebIntents intent object.
Deprecated.
On 2013/01/23 20:44:50, vsm wrote:
> If this is already deprecated in JS, why generate a Dart API?

Will discuss this with benwells.

https://codereview.chromium.org/12049030/diff/6008/tools/dom/src/chrome/app.r...
tools/dom/src/chrome/app.runtime.dart:17: Intent({String action, String type,
var data}) {
On 2013/01/23 19:28:04, Emily Fortuna wrote:
> 90% sure this constructor can be simplified to:
> 
> Intent({this.action, this.type, this.data});
> 
> here and below.

I thought so too :'( I've e-mailed misc@dartlang, but for now this gives the
error "action is not a field" when I try.

https://codereview.chromium.org/12049030/diff/6008/tools/dom/src/chrome/app.r...
tools/dom/src/chrome/app.runtime.dart:34: String get action =>
On 2013/01/23 19:28:04, Emily Fortuna wrote:
> when you have a getter with the => syntax, (and it's short), go ahead and make
> it all one line.

Will do this. Is the grouping OK? Ie should it be all getters then all setters,
or grouped by field like it is now?

https://codereview.chromium.org/12049030/diff/6008/tools/dom/src/chrome/app.r...
tools/dom/src/chrome/app.runtime.dart:110: LaunchData._proxy(_jsObject)
On 2013/01/23 19:28:04, Emily Fortuna wrote:
> same with this -- dart common style has all of this on one line.

Done.

https://codereview.chromium.org/12049030/diff/6008/tools/dom/src/chrome/app.r...
tools/dom/src/chrome/app.runtime.dart:215: => super.addListener(callback);
On 2013/01/23 19:28:04, Emily Fortuna wrote:
> if you must separate a => function onto two lines, put the "=>" on the first
> line.

Done.

https://codereview.chromium.org/12049030/diff/6008/tools/dom/src/chrome/app.r...
tools/dom/src/chrome/app.runtime.dart:247: JS('void', '#.postIntentResponse(#)',
this._jsObject, convertArgument(intentResponse));
On 2013/01/23 19:28:04, Emily Fortuna wrote:
> 80 char or less, please. :-)
> 
> here and below

Will I have to enforce this in the generated code?

https://codereview.chromium.org/12049030/diff/6008/tools/dom/src/chrome/app.w...
File tools/dom/src/chrome/app.window.dart (right):

https://codereview.chromium.org/12049030/diff/6008/tools/dom/src/chrome/app.w...
tools/dom/src/chrome/app.window.dart:333: // called on a handle to a script
context for another page, for example:
On 2013/01/23 19:28:04, Emily Fortuna wrote:
> if you make this comment triple slash, it will be be considered documentation,
> and run through our doc generator. Also, dart comments follow approximately
the
> markdown syntax http://daringfireball.net/projects/markdown/syntax, so use
> [AppWindow] (in this case we auto-link if it's already defined in the same
> class).

These comments are generated from the Chrome.* API's IDL. I can make them
triple-slash, but then they won't follow the Markdown syntax. Should I still
make them triple-slash?

https://codereview.chromium.org/12049030/diff/6008/tools/dom/src/chrome/chrom...
File tools/dom/src/chrome/chrome.dart (right):

https://codereview.chromium.org/12049030/diff/6008/tools/dom/src/chrome/chrom...
tools/dom/src/chrome/chrome.dart:11: class $API_ChromeApp {
On 2013/01/23 20:44:50, vsm wrote:
> Why the "$API_"?

To distinguish a "ChromeApp" type from this "chrome.app" class. Maybe
"APIChromeApp" would be clearer?

https://codereview.chromium.org/12049030/diff/6008/tools/dom/src/chrome/utils...
File tools/dom/src/chrome/utils.dart (right):

https://codereview.chromium.org/12049030/diff/6008/tools/dom/src/chrome/utils...
tools/dom/src/chrome/utils.dart:55: }
On 2013/01/23 20:44:50, vsm wrote:
> I'm not sure it's worth having these helper methods as opposed to just calling
> JS directly.  In this case, in particular, the type of value is likely known
at
> the call site and you can avoid the generic convertArgument call.

Is the type strongly enforced in the method signature? Ie can a user pass a
generic Object to a function that takes a String? If so, this could expose cause
security issues, but I guess this method is no more secure (other than it
enforces serializing the object, instead of assuming its of the parameter's
type)

https://codereview.chromium.org/12049030/diff/6008/tools/dom/src/chrome/utils...
tools/dom/src/chrome/utils.dart:314: * @param ruleIdentifiers If an array is
passed, only rules with identifiers contained in this array are unregistered.
On 2013/01/23 19:28:04, Emily Fortuna wrote:
> 80 char....

Done.

[sashab, 2013-01-24 22:21:33]

Added another comment.

https://codereview.chromium.org/12049030/diff/6008/tools/dom/src/chrome/utils...
File tools/dom/src/chrome/utils.dart (right):

https://codereview.chromium.org/12049030/diff/6008/tools/dom/src/chrome/utils...
tools/dom/src/chrome/utils.dart:55: }
The other reason I want to have it is this:

void set maxWidth(int maxWidth) => JS('void', '#.maxWidth = #', this._jsObject,
maxWidth);

Generates the javascript:

  set$maxWidth: function(maxWidth) {
    $.intTypeCheck(maxWidth);
    return $.voidTypeCheck(this._jsObject.maxWidth = maxWidth);
  }

and complains that the returned value is non-void.

A nice way to fix this is to call getMember instead, which then actually returns
null, and still allows the use of the => syntax.

[blois, 2013-01-26 00:45:00]

lgtm