Introduce JsStrategy skeleton

Introduce JsStrategy skeleton

This is currently an identity conversion from the frontend model but
it serves as a basis to create actual J-elements corresponding to the
K-elements.

R=sigmund@google.com

Committed: https://github.com/dart-lang/sdk/commit/1b6d8caccee4ce24f2c11d63214bbeebdd96e2cd

[Johnni Winther, 2017-06-07 18:42:48]

johnniwinther@google.com changed reviewers:
+ sigmund@google.com

[Siggi Cherem (dart-lang), 2017-06-07 22:22:50]

lgtm

https://codereview.chromium.org/2929643002/diff/1/pkg/compiler/lib/src/js_mod...
File pkg/compiler/lib/src/js_model/elements.dart (right):

https://codereview.chromium.org/2929643002/diff/1/pkg/compiler/lib/src/js_mod...
pkg/compiler/lib/src/js_model/elements.dart:24: LibraryEntity
fromFrontendLibrary(LibraryEntity library) => library;
maybe `toBackendLibrary` ?

Consider adding a dartdoc to say "front-end" is what we read in, typically
represents directly concepts in Dart and that "back-end" elements are what we
generate, and therefore may contain entities that don't exist in the sources
(like a class that represents a closure.)

Might also be worth saying which mappings you expect to be null (e.g. if you ask
toFrontEndClass(aClosureClass) you should get a null result

https://codereview.chromium.org/2929643002/diff/1/pkg/compiler/lib/src/world....
File pkg/compiler/lib/src/world.dart (right):

https://codereview.chromium.org/2929643002/diff/1/pkg/compiler/lib/src/world....
pkg/compiler/lib/src/world.dart:541: return _implementedClasses.contains(cls);
should we require that _implementedClasses is some kind of Set? To ensure this
wont accidentally become linear?

[Johnni Winther, 2017-06-08 07:24:54]

https://codereview.chromium.org/2929643002/diff/1/pkg/compiler/lib/src/js_mod...
File pkg/compiler/lib/src/js_model/elements.dart (right):

https://codereview.chromium.org/2929643002/diff/1/pkg/compiler/lib/src/js_mod...
pkg/compiler/lib/src/js_model/elements.dart:24: LibraryEntity
fromFrontendLibrary(LibraryEntity library) => library;
On 2017/06/07 22:22:49, Siggi Cherem (dart-lang) wrote:
> maybe `toBackendLibrary` ?
> 
> Consider adding a dartdoc to say "front-end" is what we read in, typically
> represents directly concepts in Dart and that "back-end" elements are what we
> generate, and therefore may contain entities that don't exist in the sources
> (like a class that represents a closure.)
> 
> Might also be worth saying which mappings you expect to be null (e.g. if you
ask
> toFrontEndClass(aClosureClass) you should get a null result
> 

Done.

https://codereview.chromium.org/2929643002/diff/1/pkg/compiler/lib/src/world....
File pkg/compiler/lib/src/world.dart (right):

https://codereview.chromium.org/2929643002/diff/1/pkg/compiler/lib/src/world....
pkg/compiler/lib/src/world.dart:541: return _implementedClasses.contains(cls);
On 2017/06/07 22:22:49, Siggi Cherem (dart-lang) wrote:
> should we require that _implementedClasses is some kind of Set? To ensure this
> wont accidentally become linear?

An ImmutableSet would be preferable!

[Johnni Winther, 2017-06-08 07:36:12]

Description was changed from

==========
Introduce JsStrategy skeleton

This is currently an identity conversion from the frontend model but
it serves as a basis to create actual J-elements corresponding to the
K-elements.
==========

to

==========
Introduce JsStrategy skeleton

This is currently an identity conversion from the frontend model but
it serves as a basis to create actual J-elements corresponding to the
K-elements.

R=sigmund@google.com

Committed:
https://github.com/dart-lang/sdk/commit/1b6d8caccee4ce24f2c11d63214bbeebdd96e2cd
==========

[Johnni Winther, 2017-06-08 07:36:14]

Committed patchset #2 (id:20001) manually as
1b6d8caccee4ce24f2c11d63214bbeebdd96e2cd (presubmit successful).