Ok folks, check it out now.
http://codereview.appspot.com/11948/diff/1/2 File doc/html/compiledModuleFormat/index.html (right): http://codereview.appspot.com/11948/diff/1/2#newcode2 Line 2: -- Copyright (C) 2008 Google Inc. On 2009/01/21 19:32:22, MikeSamuel wrote:
2009
Fixed. http://codereview.appspot.com/11948/diff/1/2#newcode25 Line 25: <script type="text/javascript" src="../common/prettify.js"></script> On 2009/01/21 19:32:22, MikeSamuel wrote:
Do we have two version of prettify? There's one under
third_party/js/prettify Well then I guess we *are* schlepping around 2 versions. :/ But the one in 3pty does not seem to have prettify.css. What's to do? http://codereview.appspot.com/11948/diff/1/2#newcode103 Line 103: code: function(___, IMPORTS___) { ... }, On 2009/01/21 19:32:22, MikeSamuel wrote:
Can we name this using a verb as per method naming conventions?
Good point. Fixed. http://codereview.appspot.com/11948/diff/1/2#newcode107 Line 107: manifest: { ...}, On 2009/01/21 19:32:22, MikeSamuel wrote:
- trailing ,
Fixed. http://codereview.appspot.com/11948/diff/1/2#newcode107 Line 107: manifest: { ...}, On 2009/01/21 19:43:40, jasvir wrote:
Other standard keys to consider: date cajoled, original source
Added date field. For the original source, this is messy: how would we represent the entire set of files? I added a field with my best guess (a simple file name -> string literal map) and made it optional. http://codereview.appspot.com/11948/diff/1/2#newcode111 Line 111: <p>The following are the standard keys:</p> On 2009/01/21 19:36:27, MarkM wrote:
Should also include an enumeration of those varnames that the module
obtains
from IMPORTS___ (which will be those vars used freely in the original
source). Fixed.
Perhaps this should include the assumed-safe static path info that
we're
currently passing to readImport?
Good point. Added a TODO. http://codereview.appspot.com/11948/diff/1/2#newcode118 Line 118: <td>The anonymous function representing the module, as before.</td> On 2009/01/21 19:32:22, MikeSamuel wrote:
Does the signature change in any way? Is the return value
significant?
Does it depend differently on any cajita.js machinery?
No, no and, _modulo_ the fact that the cajita.js machinery would just need to dig one level to call module.execute(imports) rather than module(imports), nothing new need happen. http://codereview.appspot.com/11948/diff/1/2#newcode122 Line 122: <td><code class="prettyprint">sha1sum</code></td> On 2009/01/21 19:55:55, MikeSamuel wrote:
What's the point of having a hash anyway?
Bobbitted. http://codereview.appspot.com/11948/diff/1/2#newcode123 Line 123: <td><em>required</em></td> On 2009/01/21 19:36:27, MarkM wrote:
The sha1sum should not be required. We also shouldn't use sha1. I do
not yet
know of a consensus of what to use instead.
See above. http://codereview.appspot.com/11948/diff/1/2#newcode132 Line 132: translator which emitted this module. This is an opaque value; On 2009/01/21 19:36:27, MarkM wrote:
Strings are not opaque, and it seems meaningless to require apps to
check them
only for equality. I also think equality is more severe than you want
anyway. Ok, reworded. http://codereview.appspot.com/11948/diff/1/2#newcode133 Line 133: applications may only check it for equality.</td> On 2009/01/21 19:32:22, MikeSamuel wrote:
Comparable to what? Specifically, is it comparable to any value
exported by
cajita.js?
Fixed; see current text. http://codereview.appspot.com/11948/diff/1/2#newcode141 Line 141: absent.</td> On 2009/01/21 19:32:22, MikeSamuel wrote:
This sounds like it has the potential to be larger than all the rest
of the data
in the module definition. Can we give containers enough room to be
able to
lazily fetch it?
Right ... well .... First of all, this would only be provided if a module is cajoled using debug mode so, in the common (end-user) case, this is not an issue. Making it possible to fetch that information separately means we need to define 2 formats instead of 1, and worry about the sort of contract a container would have with its server. Given the constraints, I would say this is not a biggie for now. We can always add something if it becomes a bottleneck later. http://codereview.appspot.com/11948/diff/1/2#newcode149 Line 149: the <code>cajita.manifest()</code> function.</td> On 2009/01/21 19:32:22, MikeSamuel wrote:
What is in the manifest? Is the cajita.manifest method new?
It's been in the works for a long time but we never really took it seriously. This just allocates a slot for it. As envisioned so far, cajita.manifest() is something that a module could call, passing a JSON object. This JSON gets treated as module "metadata" and is available to the runtime (and to any of a variety of downstream tools, conceivably, even ones that treat the module as text) for whatever bookkeeping needs to be done. In that respect, it is very much like a MANIFEST.MF. http://codereview.appspot.com/11948
