Move Object assign, is and mixin to polyfill directory

[arv]

Move these method out of runtime.js

See #1007

[arv]

@johnjbarton Depends on #1021

[matthewrobb]

@johnjbarton @arv Is there any reason the runtime can't exist as a collection of ES6 modules with explicit inter-dependency? Then perhaps a build task for producing a stand alone compiled version.

[johnjbarton]

We think so. But it's also a bit funky: the user's code has secret imports
and the result is transcoded to es5 so when do these imports resolve? And
the user code may not even have imports but now we force module loading on
them. And now the result depends on module loading in some way, a way that
depends upon the module loading option the user selected.

Try one, let's find out.

On Wed, May 14, 2014 at 4:08 PM, Matthew Robb [email protected]:

@johnjbarton https://github.com/johnjbarton @arvhttps://github.com/arvIs there any reason the runtime can't exist as a collection of ES6 modules
with explicit inter-dependency? Then perhaps a build task for producing a
stand alone compiled version.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/1022#issuecomment-43149295
.

[matthewrobb]

I'm saying that for now, at first, just make a decision that isn't given to the user as an option. That way at the very least you can reasonably see the dependency graph in the source files. Then add a make task for building out to a single runtime including transcompiling from modules

[johnjbarton]

To try to interpret what you are proposing: convert the runtime files to
interdependent modules and compile them into traceur-runtime.js Then
figure out how to use traceur-runtime.js to run traceur (we currently build
the runtime directly into bin/traceur.js). Then let users figure out how to
create their own custom runtimes by using a my-runtime-import.js file and
compiling it.

Is that your suggestion?

On Wed, May 14, 2014 at 4:19 PM, Matthew Robb [email protected]:

I'm saying that for now, at first, just make a decision that isn't given
to the user as an option. That way at the very least you can reasonably see
the dependency graph in the source files. Then add a make task for building
out to a single runtime including transcompiling from modules

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/1022#issuecomment-43150123
.

[matthewrobb]

Basically, if I am understanding your summary, yes.

Phase 1: Break out dependencies into modules
Phase 2: Build those modules into traceur-runtime.js
Phase 3: Expose functionality for users to configure custom builds of traceur-runtime.js

EDIT:
Internally continue to rely on traceur-runtime.js as a single stand alone include and as a bundled include for bin/traceur.js

EDIT (again):
Maybe move some of the pieces of the runtime into other repos, the polyfills for example could be useful by themselves.

[johnjbarton]

Phase 0: verify that we can create a bin/traceur.js from
bin/traceur-runtime.js, whether or not bin/traceur-runtime is built by
modules. Probably, but this is a show stopper.

On Wed, May 14, 2014 at 4:31 PM, Matthew Robb [email protected]:

Basically, if I am understanding your summary, yes.

Phase 1: Break out dependencies into modules
Phase 2: Build those modules into traceur-runtime.js
Phase 3: Expose functionality for users to configure custom builds of
traceur-runtime.js

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/1022#issuecomment-43151008
.

[johnjbarton]

@matthewrobb please open an issue or find one existing for modular runtime (I guess there may be a couple) and put your suggestion there. This PR will not be tracked soon....