Confirmed users
396
edits
Labs/Jetpack/JEP/13: Difference between revisions
m
grammar fix: quiet > quite
No edit summary |
m (grammar fix: quiet > quite) |
||
| (5 intermediate revisions by 2 users not shown) | |||
| Line 15: | Line 15: | ||
This JEP describes a method for enabling experimentation with experimental Jetpack features, or features that aren't stable/frozen. | This JEP describes a method for enabling experimentation with experimental Jetpack features, or features that aren't stable/frozen. | ||
There is a tension in Jetpack development between (a) moving quickly and being agile, and (b) creating solid APIs that are future proof. We need to have and be both. As a way to compromise, this JEP proposes adding an import mechanism that allows access to not- | There is a tension in Jetpack development between (a) moving quickly and being agile, and (b) creating solid APIs that are future proof. We need to have and be both. As a way to compromise, this JEP proposes adding an import mechanism that allows access to not-quite-yet-ready Jetpack features. | ||
One of the requirements for this import mechanism is that as few code changes are required for any particular Jetpack as a feature is moved from experimental to permanently in the core. | One of the requirements for this import mechanism is that as few code changes are required for any particular Jetpack as a feature is moved from experimental to permanently in the core. | ||
| Line 35: | Line 35: | ||
The general syntax for importing from the future is as follows: | The general syntax for importing from the future is as follows: | ||
<pre class="brush: | <pre class="brush:js;toolbar:false;">jetpack.future.import( stringMountPath )</pre> | ||
Where <code>stringMountPath</code> is a string that enumerates where, starting from the <code>jetpack</code> base, the feature will be mounted. To get a list of what mount paths are available, see the "Reading the Future" section below. Some examples of using <code> | Where <code>stringMountPath</code> is a string that enumerates where, starting from the <code>jetpack</code> base, the feature will be mounted. To get a list of what mount paths are available, see the "Reading the Future" section below. Some examples of using <code>future.import</code> are as folows: | ||
<pre class="brush:js;> | <pre class="brush:js;toolbar:false;"> | ||
// jetpack.storage.sqlite is currently undefined. | // jetpack.storage.sqlite is currently undefined. | ||
jetpack. | jetpack.future.import("storage.sqlite"); | ||
var mydb = jetpack.storage.sqlite.create("blah"); | var mydb = jetpack.storage.sqlite.create("blah"); | ||
// jetpack.T1000 is currently undefined | // jetpack.T1000 is currently undefined | ||
jetpack. | jetpack.future.import("T1000"); | ||
jetpack.T1000(); | jetpack.T1000(); | ||
</pre> | </pre> | ||
| Line 51: | Line 51: | ||
The nice thing about such syntax is that once storage.sqlite is formally | The nice thing about such syntax is that once storage.sqlite is formally | ||
accepted into the core, the author can just remove the | accepted into the core, the author can just remove the | ||
jetpack. | jetpack.future.import() call and their code will "just work" (barring any | ||
other changes that were made when the functionality was integrated into the | other changes that were made when the functionality was integrated into the | ||
core, of course). | core, of course). | ||
| Line 59: | Line 59: | ||
To determine what features are importable from the future, use: | To determine what features are importable from the future, use: | ||
<pre class="brush:js;toolbar:false;">jetpack. | <pre class="brush:js;toolbar:false;">var list = jetpack.future.list()</pre> | ||
It returns an array containing the set of potential <code>stringMountPath</code> as used in <code>jetpack.future.import()</code>. | |||