577
edits
Labs/Jetpack/JEP/13: Difference between revisions
Jump to navigation
Jump to search
no edit summary
(Created page with 'We need to have some functionality for easily accessing experimental functionality that may be added in the future, but whose APIs are likely to change. It needs to also be easy ...') |
No edit summary |
||
| Line 1: | Line 1: | ||
{{draft}} | |||
== JEP 13 - Enabling Experimental Jetpack Features == | |||
* Champion: Aza Raskin <aza at mozilla dot com> | |||
* Editors: Atul Varma <atul at mozilla dot com> | |||
* Status: Implementing | |||
* Type: API Track | |||
* Created: 5 June 2009 | |||
* Reference Implementation: None | |||
* [[Labs/Jetpack/JEPs|JEP Index]] | |||
=== Introduction and Rationale === | |||
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-quiet-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. | |||
=== Proposal === | |||
We need to have some functionality for easily accessing experimental | We need to have some functionality for easily accessing experimental | ||
functionality that may be added in the future, but whose APIs are likely to | functionality that may be added in the future, but whose APIs are likely to | ||
change | change. | ||
Inspiration for this comes from Python's __future__ module | Inspiration for this comes from Python's [http://docs.python.org/library/__future__.html __future__ module]. Essentially, in Python you can call | ||
<pre class="brush:python;toolbar:false;">from __future__ import foo</pre> | |||
which adds whatever functionality that <code>foo</code> yields to the Python script you are writing. In Jetpack, we do not have the same syntax as Python, so instead we propose adding a new function to the base namespace of Jetpack called <code>importFromFuture</code>. | |||
==== Importing the Future ==== | |||
The general syntax for importing from the future is as follows: | |||
<pre class="brush:pre;toolbar:false;">jetpack.importFromFuture( 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>importFromFuture</code> are as folows: | |||
<pre class="brush:js;> | |||
// jetpack.storage.sqlite is currently undefined. | |||
jetpack.importFromFuture("storage.sqlite"); | |||
var mydb = jetpack.storage.sqlite.create("blah"); | |||
// jetpack.T1000 is currently undefined | |||
jetpack.importFromFuture("T1000"); | |||
jetpack.T1000(); | |||
</pre> | |||
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 | ||
| Line 19: | Line 55: | ||
core, of course). | core, of course). | ||
==== Reading the Future ==== | |||
To determine what features are importable from the future, use: | |||
<pre class="brush:js;toolbar:false;">jetpack.importFromFuture.list()</pre> | |||