Introduce boot.js: this finally makes it possible to load and run Todomvc

Introduce boot.js: this finally makes it possible to load and run Todomvc
without using a compiler.

[Siggi Cherem (dart-lang), 2013-07-26 23:33:31]

I still need to fix up tests and fix the other samples, but here is a first look
at the changes.

[Jennifer Messerly, 2013-07-27 02:18:44]

this is lovely!

https://chromiumcodereview.appspot.com/20863002/diff/3001/example/todomvc/web...
File example/todomvc/web/editable_label.dart (right):

https://chromiumcodereview.appspot.com/20863002/diff/3001/example/todomvc/web...
example/todomvc/web/editable_label.dart:37: notifyChange(new
PropertyChangeRecord(const Symbol('editing')));
you shouldn't need this line

https://chromiumcodereview.appspot.com/20863002/diff/3001/example/todomvc/web...
example/todomvc/web/editable_label.dart:42: runAsync(() => runAsync(() {
add TODO explaining the issue here?

https://chromiumcodereview.appspot.com/20863002/diff/3001/example/todomvc/web...
File example/todomvc/web/index.html (right):

https://chromiumcodereview.appspot.com/20863002/diff/3001/example/todomvc/web...
example/todomvc/web/index.html:13: <script
src='packages/polymer/boot.js'></script>
probably we should include this in boot.js?

https://chromiumcodereview.appspot.com/20863002/diff/3001/lib/boot.js
File lib/boot.js (right):

https://chromiumcodereview.appspot.com/20863002/diff/3001/lib/boot.js#newcode52
lib/boot.js:52: if (!navigator.webkitStartDart) return;
should we print a console message?

"boot.js only works in Dartium, you should run XYZ tool to compile a depolyable
JavaScript version?"

https://chromiumcodereview.appspot.com/20863002/diff/3001/lib/boot.js#newcode73
lib/boot.js:73: if (url && url != '') {
second check is unnecessary, empty string is false in JS

https://chromiumcodereview.appspot.com/20863002/diff/3001/lib/boot.js#newcode80
lib/boot.js:80: // TODO(sigmund): remove the timestamp. We added this to work
around
awesome workaround, btw!

https://chromiumcodereview.appspot.com/20863002/diff/3001/lib/boot.js#newcode88
lib/boot.js:88: // TODO(sigmund): investigate how to eliminate the warning in
Dartium
curious, what is the warning?

https://chromiumcodereview.appspot.com/20863002/diff/3001/lib/boot.js#newcode94
lib/boot.js:94: // Moves <polymer-elements> from imported documents into the
top-level page.
does html_imports/polymer do this too?

instead of moving elements, we might want to consider changing our query logic
that finds polymer-elements to include the `<linkrel=import>` nodes and dig into
the associated document/fragment

can happen later of course, this is already a **huge** step in the right
direction

https://chromiumcodereview.appspot.com/20863002/diff/3001/lib/observe.dart
File lib/observe.dart (right):

https://chromiumcodereview.appspot.com/20863002/diff/3001/lib/observe.dart#ne...
lib/observe.dart:115: _subs.add(pathObs.bindSync(_scheduleReduce));
this should be:

  pathObs.changes.listen(_scheduleReduce);

... so it won't schedule if not needed. bindSync will pass the value
immediately.

https://chromiumcodereview.appspot.com/20863002/diff/3001/lib/observe.dart#ne...
lib/observe.dart:127: setValueWorkaround(key, value) {}
these 2 lines be removed

https://chromiumcodereview.appspot.com/20863002/diff/3001/lib/polymer.dart
File lib/polymer.dart (right):

https://chromiumcodereview.appspot.com/20863002/diff/3001/lib/polymer.dart#ne...
lib/polymer.dart:15: import 'dart:mirrors';
show currentMirrorSystem?

https://chromiumcodereview.appspot.com/20863002/diff/3001/lib/polymer.dart#ne...
lib/polymer.dart:22: export 'observe.dart';
also re-export 'package:observe/observe.dart"?

https://chromiumcodereview.appspot.com/20863002/diff/3001/lib/polymer.dart#ne...
lib/polymer.dart:37: lib.invoke(const Symbol("_init"), const []);
lookup "_init" symbol rather than try+catch?

should be able to use
http://api.dartlang.org/docs/bleeding_edge/dart_mirrors/LibraryMirror.html#fu...

for instance properties try+catch is required because of noSuchMethod, but
fortunately, libraries can't implement NSM :)

https://chromiumcodereview.appspot.com/20863002/diff/3001/lib/polymer.dart#ne...
lib/polymer.dart:46: initializePolymer(List<String> elementLibraries, Function
userMain) {
initPolymer?

https://chromiumcodereview.appspot.com/20863002/diff/3001/lib/polymer.dart#ne...
lib/polymer.dart:46: initializePolymer(List<String> elementLibraries, Function
userMain) {
"void userMain()" ?

https://chromiumcodereview.appspot.com/20863002/diff/3001/lib/polymer.dart#ne...
lib/polymer.dart:47: new Timer.periodic(new Duration(milliseconds: 60),
it's arbitrary either way, but consider using 125ms like polymer?

https://github.com/Polymer/platform/blob/master/src/patches-mdv.js#L26

https://chromiumcodereview.appspot.com/20863002/diff/3001/lib/polymer.dart#ne...
lib/polymer.dart:49: mdv.initialize();
TODO(jmesserly): mdv should use initializeMdv instead of mdv.initialize

[Siggi Cherem (dart-lang), 2013-07-30 00:10:29]

Thanks John!

PTAL. Here is a new version which declares the register-polymer-element using a
meta annotation. This code works dynamically (no compiler), but almost works
when using build.dart. I think todomvc was affected by some of the recent
changes in observe & mdv. Let's chat when you get a chance.

https://chromiumcodereview.appspot.com/20863002/diff/3001/example/todomvc/web...
File example/todomvc/web/editable_label.dart (right):

https://chromiumcodereview.appspot.com/20863002/diff/3001/example/todomvc/web...
example/todomvc/web/editable_label.dart:37: notifyChange(new
PropertyChangeRecord(const Symbol('editing')));
On 2013/07/27 02:18:44, John Messerly wrote:
> you shouldn't need this line

Done.

https://chromiumcodereview.appspot.com/20863002/diff/3001/example/todomvc/web...
example/todomvc/web/editable_label.dart:42: runAsync(() => runAsync(() {
On 2013/07/27 02:18:44, John Messerly wrote:
> add TODO explaining the issue here?

Done.

https://chromiumcodereview.appspot.com/20863002/diff/3001/example/todomvc/web...
File example/todomvc/web/index.html (right):

https://chromiumcodereview.appspot.com/20863002/diff/3001/example/todomvc/web...
example/todomvc/web/index.html:13: <script
src='packages/polymer/boot.js'></script>
On 2013/07/27 02:18:44, John Messerly wrote:
> probably we should include this in boot.js?

do you mean to include html_import.min.js? If so, done =)

https://chromiumcodereview.appspot.com/20863002/diff/3001/lib/boot.js
File lib/boot.js (right):

https://chromiumcodereview.appspot.com/20863002/diff/3001/lib/boot.js#newcode52
lib/boot.js:52: if (!navigator.webkitStartDart) return;
On 2013/07/27 02:18:44, John Messerly wrote:
> should we print a console message?
> 
> "boot.js only works in Dartium, you should run XYZ tool to compile a
depolyable
> JavaScript version?"

Done.

https://chromiumcodereview.appspot.com/20863002/diff/3001/lib/boot.js#newcode73
lib/boot.js:73: if (url && url != '') {
On 2013/07/27 02:18:44, John Messerly wrote:
> second check is unnecessary, empty string is false in JS

Done.

https://chromiumcodereview.appspot.com/20863002/diff/3001/lib/boot.js#newcode88
lib/boot.js:88: // TODO(sigmund): investigate how to eliminate the warning in
Dartium
On 2013/07/27 02:18:44, John Messerly wrote:
> curious, what is the warning?

In the console you'd see a message of this form:

Resource interpreted as Script but transferred with MIME type application/dart:
"data:application/dart;base64,IG1haW4oKSB7IH0g".

https://chromiumcodereview.appspot.com/20863002/diff/3001/lib/boot.js#newcode94
lib/boot.js:94: // Moves <polymer-elements> from imported documents into the
top-level page.
On 2013/07/27 02:18:44, John Messerly wrote:
> does html_imports/polymer do this too?
> 
> instead of moving elements, we might want to consider changing our query logic
> that finds polymer-elements to include the `<linkrel=import>` nodes and dig
into
> the associated document/fragment
> 
> can happen later of course, this is already a **huge** step in the right
> direction

Exactly =), I was planning to do so as a next step. The main missing piece is to
provide access to linkrel-imports from Dart.

https://chromiumcodereview.appspot.com/20863002/diff/3001/lib/observe.dart
File lib/observe.dart (right):

https://chromiumcodereview.appspot.com/20863002/diff/3001/lib/observe.dart#ne...
lib/observe.dart:115: _subs.add(pathObs.bindSync(_scheduleReduce));
On 2013/07/27 02:18:44, John Messerly wrote:
> this should be:
> 
>   pathObs.changes.listen(_scheduleReduce);
> 
> ... so it won't schedule if not needed. bindSync will pass the value
> immediately.

Done. Thanks, I saw 'values' went away, but didn't realize that it was replaced
by 'changes'.

https://chromiumcodereview.appspot.com/20863002/diff/3001/lib/observe.dart#ne...
lib/observe.dart:127: setValueWorkaround(key, value) {}
On 2013/07/27 02:18:44, John Messerly wrote:
> these 2 lines be removed

Done.

https://chromiumcodereview.appspot.com/20863002/diff/3001/lib/polymer.dart
File lib/polymer.dart (right):

https://chromiumcodereview.appspot.com/20863002/diff/3001/lib/polymer.dart#ne...
lib/polymer.dart:15: import 'dart:mirrors';
On 2013/07/27 02:18:44, John Messerly wrote:
> show currentMirrorSystem?

Done.

https://chromiumcodereview.appspot.com/20863002/diff/3001/lib/polymer.dart#ne...
lib/polymer.dart:22: export 'observe.dart';
On 2013/07/27 02:18:44, John Messerly wrote:
> also re-export 'package:observe/observe.dart"?

Done.

https://chromiumcodereview.appspot.com/20863002/diff/3001/lib/polymer.dart#ne...
lib/polymer.dart:37: lib.invoke(const Symbol("_init"), const []);
On 2013/07/27 02:18:44, John Messerly wrote:
> lookup "_init" symbol rather than try+catch?
> 
> should be able to use
>
http://api.dartlang.org/docs/bleeding_edge/dart_mirrors/LibraryMirror.html#fu...
> 
> for instance properties try+catch is required because of noSuchMethod, but
> fortunately, libraries can't implement NSM :)

Done. Then found out that "_init" gives me errors when compiling with dart2js
(even though this code is unreachable in that case). Nevertheless, this
motivated me to implement the @CustomTag annotation.

https://chromiumcodereview.appspot.com/20863002/diff/3001/lib/polymer.dart#ne...
lib/polymer.dart:46: initializePolymer(List<String> elementLibraries, Function
userMain) {
On 2013/07/27 02:18:44, John Messerly wrote:
> initPolymer?

Done.

https://chromiumcodereview.appspot.com/20863002/diff/3001/lib/polymer.dart#ne...
lib/polymer.dart:46: initializePolymer(List<String> elementLibraries, Function
userMain) {
On 2013/07/27 02:18:44, John Messerly wrote:
> "void userMain()" ?

Done.

https://chromiumcodereview.appspot.com/20863002/diff/3001/lib/polymer.dart#ne...
lib/polymer.dart:47: new Timer.periodic(new Duration(milliseconds: 60),
On 2013/07/27 02:18:44, John Messerly wrote:
> it's arbitrary either way, but consider using 125ms like polymer?
> 
> https://github.com/Polymer/platform/blob/master/src/patches-mdv.js#L26

Done.

https://chromiumcodereview.appspot.com/20863002/diff/3001/lib/polymer.dart#ne...
lib/polymer.dart:49: mdv.initialize();
On 2013/07/27 02:18:44, John Messerly wrote:
> TODO(jmesserly): mdv should use initializeMdv instead of mdv.initialize

Done.

[Jennifer Messerly, 2013-07-30 00:56:12]

https://chromiumcodereview.appspot.com/20863002/diff/12001/example/component/...
File example/component/news/web/news-component.html (right):

https://chromiumcodereview.appspot.com/20863002/diff/12001/example/component/...
example/component/news/web/news-component.html:42: _init() {
is _init still supported?

https://chromiumcodereview.appspot.com/20863002/diff/12001/example/todomvc/we...
File example/todomvc/web/index.html (right):

https://chromiumcodereview.appspot.com/20863002/diff/12001/example/todomvc/we...
example/todomvc/web/index.html:12: <script
src='packages/polymer/boot.js'></script>
any reason to have this before instead of after the stylesheet?

https://chromiumcodereview.appspot.com/20863002/diff/12001/lib/polymer.dart
File lib/polymer.dart (right):

https://chromiumcodereview.appspot.com/20863002/diff/12001/lib/polymer.dart#n...
lib/polymer.dart:42: * with the [CustomTag] annotation.
did we lose support for "_init"? I'm worried a little worried about that--it
means we have less features than JS does (no place to do top-level
initialization)... I like CustomTag as sugar but it seems like it's now
required?

https://chromiumcodereview.appspot.com/20863002/diff/12001/lib/src/emitters.dart
File lib/src/emitters.dart (right):

https://chromiumcodereview.appspot.com/20863002/diff/12001/lib/src/emitters.d...
lib/src/emitters.dart:268: ..addLine('mdv.initialize();');
remove this because initPolymer does it?

(shouldn't we be calling initPolymer even if compiling? One of my hopes in
moving towards a runtime system is we don't end up maintaining two code paths;
the compiler might do some preprocessing to consolidate HTML files, but
ultimately it all ends up int the same runtime Polymer system.)

https://chromiumcodereview.appspot.com/20863002/diff/12001/lib/src/observable...
File lib/src/observable_transform.dart (right):

https://chromiumcodereview.appspot.com/20863002/diff/12001/lib/src/observable...
lib/src/observable_transform.dart:92: if (id is PrefixedIdentifier) {
it's only used in 2 places but this might be a good candidate for a function:

SimpleIdentifier getSimpleIdentifier(Identifier id) =>
    id is PrefixedIdentifier ? id.identifier : id;

https://chromiumcodereview.appspot.com/20863002/diff/12001/lib/src/observable...
lib/src/observable_transform.dart:136: if (!declaresObservable) {
I'm not sure this warning is correct. What if Observable* comes from somewhere
up the inheritance hierarchy? Or if someone chose to implement the Observable
interface themselves...

[Siggi Cherem (dart-lang), 2013-07-30 23:32:03]

Thanks John - ptal

https://chromiumcodereview.appspot.com/20863002/diff/12001/example/component/...
File example/component/news/web/news-component.html (right):

https://chromiumcodereview.appspot.com/20863002/diff/12001/example/component/...
example/component/news/web/news-component.html:42: _init() {
On 2013/07/30 00:56:12, John Messerly wrote:
> is _init still supported?

Done. restored.

https://chromiumcodereview.appspot.com/20863002/diff/12001/example/todomvc/we...
File example/todomvc/web/index.html (right):

https://chromiumcodereview.appspot.com/20863002/diff/12001/example/todomvc/we...
example/todomvc/web/index.html:12: <script
src='packages/polymer/boot.js'></script>
On 2013/07/30 00:56:12, John Messerly wrote:
> any reason to have this before instead of after the stylesheet?

no reason, it could go anywhere

https://chromiumcodereview.appspot.com/20863002/diff/12001/lib/polymer.dart
File lib/polymer.dart (right):

https://chromiumcodereview.appspot.com/20863002/diff/12001/lib/polymer.dart#n...
lib/polymer.dart:42: * with the [CustomTag] annotation.
On 2013/07/30 00:56:12, John Messerly wrote:
> did we lose support for "_init"? I'm worried a little worried about that--it
> means we have less features than JS does (no place to do top-level
> initialization)... I like CustomTag as sugar but it seems like it's now
> required?

Ok, I added it back. Now we have both options. I changed todomvc to illustrate
using both kinds of initialization.

https://chromiumcodereview.appspot.com/20863002/diff/12001/lib/src/emitters.dart
File lib/src/emitters.dart (right):

https://chromiumcodereview.appspot.com/20863002/diff/12001/lib/src/emitters.d...
lib/src/emitters.dart:268: ..addLine('mdv.initialize();');
On 2013/07/30 00:56:12, John Messerly wrote:
> remove this because initPolymer does it?
> 
> (shouldn't we be calling initPolymer even if compiling? One of my hopes in
> moving towards a runtime system is we don't end up maintaining two code paths;
> the compiler might do some preprocessing to consolidate HTML files, but
> ultimately it all ends up int the same runtime Polymer system.)

I changed it to do so, but we should talk more about it. My hope is that we can
reduce most uses of mirrors when we compile for deployment. This is one case
where we could potentially do that.

https://chromiumcodereview.appspot.com/20863002/diff/12001/lib/src/observable...
File lib/src/observable_transform.dart (right):

https://chromiumcodereview.appspot.com/20863002/diff/12001/lib/src/observable...
lib/src/observable_transform.dart:92: if (id is PrefixedIdentifier) {
On 2013/07/30 00:56:12, John Messerly wrote:
> it's only used in 2 places but this might be a good candidate for a function:
> 
> SimpleIdentifier getSimpleIdentifier(Identifier id) =>
>     id is PrefixedIdentifier ? id.identifier : id;

Done.

https://chromiumcodereview.appspot.com/20863002/diff/12001/lib/src/observable...
lib/src/observable_transform.dart:136: if (!declaresObservable) {
On 2013/07/30 00:56:12, John Messerly wrote:
> I'm not sure this warning is correct. What if Observable* comes from somewhere
> up the inheritance hierarchy? Or if someone chose to implement the Observable
> interface themselves...

Good point. Since we are not going to do a type analysis here, I am trying to
think of good heuristics of when to show this message.

If we want to show it only when we are sure, then we have to only do this when
there is no superclass, no mixin, and no observable interface.

However, I think it's going to be fairly common to have cases where people have
baseclasses/mixins but they are not doing things right. One heuristic to take is
that we'll report a warning in those cases, unless the interface is present. 

So if I have:

A implements Observable {
}
...

B extends A {
}

I'll see a warning in B, but if you write again B extends A implements
Observable, the warning goes away.

Thoughts?

https://chromiumcodereview.appspot.com/20863002/diff/64001/lib/testing/conten...
File lib/testing/content_shell_test.dart (right):

https://chromiumcodereview.appspot.com/20863002/diff/64001/lib/testing/conten...
lib/testing/content_shell_test.dart:81: for (var filename in filenames) {
I'm splitting each content_shell run to be separate from the others, seems to
give us more consistent results than trying to run multiple at once =(

https://chromiumcodereview.appspot.com/20863002/diff/64001/pubspec.yaml
File pubspec.yaml (right):

https://chromiumcodereview.appspot.com/20863002/diff/64001/pubspec.yaml#newco...
pubspec.yaml:24: custom_element: ">=0.6.13"
this is not published yet, but I plan to publish a preliminary version before
submitting this

[Jennifer Messerly, 2013-07-31 00:59:51]

https://chromiumcodereview.appspot.com/20863002/diff/12001/lib/src/observable...
File lib/src/observable_transform.dart (right):

https://chromiumcodereview.appspot.com/20863002/diff/12001/lib/src/observable...
lib/src/observable_transform.dart:136: if (!declaresObservable) {
On 2013/07/30 23:32:04, Siggi Cherem (dart-lang) wrote:
> On 2013/07/30 00:56:12, John Messerly wrote:
> > I'm not sure this warning is correct. What if Observable* comes from
somewhere
> > up the inheritance hierarchy? Or if someone chose to implement the
Observable
> > interface themselves...
> 
> Good point. Since we are not going to do a type analysis here, I am trying to
> think of good heuristics of when to show this message.
> 
> If we want to show it only when we are sure, then we have to only do this when
> there is no superclass, no mixin, and no observable interface.
> 
> However, I think it's going to be fairly common to have cases where people
have
> baseclasses/mixins but they are not doing things right. One heuristic to take
is
> that we'll report a warning in those cases, unless the interface is present. 
> 
> So if I have:
> 
> A implements Observable {
> }
> ...
> 
> B extends A {
> }
> 
> I'll see a warning in B, but if you write again B extends A implements
> Observable, the warning goes away.
> 
> Thoughts?

Hmm, sounds a little better, but I get nervous any time we're issuing a warning
for valid code. For historical reasons we may see this incorrect usage for a
while, but anyone coming to Polymer.dart fresh is unlikely to make that mistake.

Other ideas:
* use type resolution
* turn it into a runtime diagnostic feature. We could make a "debugDataBinding"
function that scans the DOM for any bindings that have mutable fields. This
would also detect missing @observable or incorrect List usage, which are perhaps
even more common errors.

[Siggi Cherem (dart-lang), 2013-07-31 01:39:17]

thanks!

https://chromiumcodereview.appspot.com/20863002/diff/12001/lib/src/observable...
File lib/src/observable_transform.dart (right):

https://chromiumcodereview.appspot.com/20863002/diff/12001/lib/src/observable...
lib/src/observable_transform.dart:136: if (!declaresObservable) {
On 2013/07/31 00:59:51, John Messerly wrote:
> On 2013/07/30 23:32:04, Siggi Cherem (dart-lang) wrote:
> > On 2013/07/30 00:56:12, John Messerly wrote:
> > > I'm not sure this warning is correct. What if Observable* comes from
> somewhere
> > > up the inheritance hierarchy? Or if someone chose to implement the
> Observable
> > > interface themselves...
> > 
> > Good point. Since we are not going to do a type analysis here, I am trying
to
> > think of good heuristics of when to show this message.
> > 
> > If we want to show it only when we are sure, then we have to only do this
when
> > there is no superclass, no mixin, and no observable interface.
> > 
> > However, I think it's going to be fairly common to have cases where people
> have
> > baseclasses/mixins but they are not doing things right. One heuristic to
take
> is
> > that we'll report a warning in those cases, unless the interface is present.

> > 
> > So if I have:
> > 
> > A implements Observable {
> > }
> > ...
> > 
> > B extends A {
> > }
> > 
> > I'll see a warning in B, but if you write again B extends A implements
> > Observable, the warning goes away.
> > 
> > Thoughts?
> 
> Hmm, sounds a little better, but I get nervous any time we're issuing a
warning
> for valid code. For historical reasons we may see this incorrect usage for a
> while, but anyone coming to Polymer.dart fresh is unlikely to make that
mistake.
> 
> Other ideas:
> * use type resolution
> * turn it into a runtime diagnostic feature. We could make a
"debugDataBinding"
> function that scans the DOM for any bindings that have mutable fields. This
> would also detect missing @observable or incorrect List usage, which are
perhaps
> even more common errors.

good ideas, I'll think more about them. For now I changed this just to provide
errors when we know for sure.

[Jennifer Messerly, 2013-07-31 01:51:33]

LGTM!

https://chromiumcodereview.appspot.com/20863002/diff/69001/lib/polymer.dart
File lib/polymer.dart (right):

https://chromiumcodereview.appspot.com/20863002/diff/69001/lib/polymer.dart#n...
lib/polymer.dart:43: const init_polymer = const _InitPolymerAnnotation();
this should be camelCase right, per naming guidelines?

https://chromiumcodereview.appspot.com/20863002/diff/69001/lib/src/observable...
File lib/src/observable_transform.dart (right):

https://chromiumcodereview.appspot.com/20863002/diff/69001/lib/src/observable...
lib/src/observable_transform.dart:101: } else if (id.name != 'PolymerElement' &&
id.name != 'Object') {
include CustomElement too?

https://chromiumcodereview.appspot.com/20863002/diff/69001/lib/src/observable...
lib/src/observable_transform.dart:119: // TODO(sigmund): this is conservative,
consider using type-resolution to
long line

https://chromiumcodereview.appspot.com/20863002/diff/69001/pubspec.yaml
File pubspec.yaml (right):

https://chromiumcodereview.appspot.com/20863002/diff/69001/pubspec.yaml#newco...
pubspec.yaml:24: custom_element: ">=0.6.13"
sort?

[Siggi Cherem (dart-lang), 2013-07-31 02:17:28]

all set, thanks!

https://chromiumcodereview.appspot.com/20863002/diff/69001/lib/polymer.dart
File lib/polymer.dart (right):

https://chromiumcodereview.appspot.com/20863002/diff/69001/lib/polymer.dart#n...
lib/polymer.dart:43: const init_polymer = const _InitPolymerAnnotation();
On 2013/07/31 01:51:33, John Messerly wrote:
> this should be camelCase right, per naming guidelines?

Done, renamed to initPolymerMethod.

BTW, your suggestion makes sense, but I also like how lower_name stands out for
metadata. I didn't find anything in the guide, so maybe a question for Bob =)?

https://chromiumcodereview.appspot.com/20863002/diff/69001/lib/src/observable...
File lib/src/observable_transform.dart (right):

https://chromiumcodereview.appspot.com/20863002/diff/69001/lib/src/observable...
lib/src/observable_transform.dart:101: } else if (id.name != 'PolymerElement' &&
id.name != 'Object') {
On 2013/07/31 01:51:33, John Messerly wrote:
> include CustomElement too?

Done

https://chromiumcodereview.appspot.com/20863002/diff/69001/lib/src/observable...
lib/src/observable_transform.dart:119: // TODO(sigmund): this is conservative,
consider using type-resolution to
On 2013/07/31 01:51:33, John Messerly wrote:
> long line

Done.

https://chromiumcodereview.appspot.com/20863002/diff/69001/pubspec.yaml
File pubspec.yaml (right):

https://chromiumcodereview.appspot.com/20863002/diff/69001/pubspec.yaml#newco...
pubspec.yaml:24: custom_element: ">=0.6.13"
On 2013/07/31 01:51:33, John Messerly wrote:
> sort?

Done.

[Jennifer Messerly, 2013-07-31 02:18:49]

https://chromiumcodereview.appspot.com/20863002/diff/69001/lib/polymer.dart
File lib/polymer.dart (right):

https://chromiumcodereview.appspot.com/20863002/diff/69001/lib/polymer.dart#n...
lib/polymer.dart:43: const init_polymer = const _InitPolymerAnnotation();
On 2013/07/31 02:17:29, Siggi Cherem (dart-lang) wrote:
> On 2013/07/31 01:51:33, John Messerly wrote:
> > this should be camelCase right, per naming guidelines?
> 
> Done, renamed to initPolymerMethod.
> 
> BTW, your suggestion makes sense, but I also like how lower_name stands out
for
> metadata. I didn't find anything in the guide, so maybe a question for Bob =)?

yeah, definitely worth discussing

[Siggi Cherem (dart-lang), 2013-07-31 02:19:04]

commit submitted at
https://github.com/dart-lang/web-ui/commit/bad34509fa372bdfe648a71f8d136dc0f7...