diff options
| author | Joseph Richey <joerichey@google.com> | 2017-11-15 08:48:14 -0800 |
|---|---|---|
| committer | JF Bastien <github@jfbastien.com> | 2017-11-15 09:48:14 -0700 |
| commit | e2be77eaac770268a4c22fb09c6f648de7b9b6b8 (patch) | |
| tree | ba99bc504cd96f6471147582e08a5e19ebd8312d /FAQ.md | |
| parent | 71c97d9081ac6d64497d586e8f45c8145ed3f86e (diff) | |
| download | nanowasm-design-e2be77eaac770268a4c22fb09c6f648de7b9b6b8.tar.gz | |
Fixup links to future features (#1157)
This link standardizes how all the other design pages will refer to
future features (either in `FutureFeatures.md` or in a tracking issue).
All links to these upcoming features now use references at the bottom of
the doc page (as opposed to inline links or references).
Note that this change makes it very easy for the doc links to be updated
when a tracking issue is started. As all the references have a standard
format; a simple find/replace script will get everything.
This commit also makes sure that references now point to a tracking
issue if one exists. Note that this means a future CL can now delete
some of the unnecessary sections from `FutureFeatures.md`.
The only visible change from this commit is that certain broken links
are now fixed, or links pointing to a doc section now point to the
correct tracking issue.
Diffstat (limited to 'FAQ.md')
| -rw-r--r-- | FAQ.md | 10 |
1 files changed, 5 insertions, 5 deletions
@@ -24,7 +24,7 @@ There are two main benefits WebAssembly provides: 2. By avoiding the simultaneous asm.js constraints of [AOT][]-[compilability][] and good performance even on engines without [specific asm.js optimizations][], a new standard makes it *much easier* to - add the [features :unicorn:][future features] required to reach native + add the [features :unicorn:][future general] required to reach native levels of performance. [experiments]: BinaryEncoding.md#why-a-binary-encoding-instead-of-a-text-only-representation @@ -96,7 +96,7 @@ reusing a modular C++ library can be as simple as [using a module from JavaScrip Beyond the MVP, another [high-level goal](HighLevelGoals.md) is to improve support for languages other than C/C++. This includes [allowing WebAssembly code to allocate and access garbage-collected (JavaScript, DOM, Web API) objects -:unicorn:][future dom]. +:unicorn:][future garbage collection]. Even before GC support is added to WebAssembly, it is possible to compile a language's VM to WebAssembly (assuming it's written in portable C/C++) and this has already been demonstrated ([1](http://ruby.dj), [2](https://kripken.github.io/lua.vm.js/lua.vm.js.html), @@ -178,7 +178,7 @@ together in a number of configurations: today) allowing developers to reuse popular WebAssembly libraries just like JavaScript libraries today. * When WebAssembly - [gains the ability to access garbage-collected objects :unicorn:][future dom], + [gains the ability to access garbage-collected objects :unicorn:][future garbage collection], those objects will be shared with JavaScript, and not live in a walled-off world of their own. @@ -390,7 +390,7 @@ accessible through regular JavaScript. However, if a wasm VM is provided as an access to [proprietary platform-specific APIs](Portability.md#api) of e.g. Android / iOS. -[future features]: FutureFeatures.md -[future dom]: FutureFeatures.md#gcdom-integration +[future general]: FutureFeatures.md +[future garbage collection]: https://github.com/WebAssembly/design/issues/1079 [future floating point]: FutureFeatures.md#additional-floating-point-operators [future memory control]: FutureFeatures.md#finer-grained-control-over-memory |