Comments (17)
I am actively bored reading the word "descriptor". Truly, I do not hate it. (Maybe this is actually high praise?)
from proposal-source-phase-imports.
From the Module Harmony call today, we found our way to descriptor
as an option that we collectively neither love nor hate, but it does avoid some problems we acknowledge with source
and many of its alternatives. One potential guiding principle for naming this phase would be:
Each phase should describe itself and not its relationship to a neighboring phase.
The object in question is a handle, potentially opaque, that describes the bindings and behavior the module system will need to link and execute the module in a later-specified context. The handle does not even necessarily retail the source text, since the behavior depends only on the resulting object code. There handle may not even retain code, since a virtualization would model the behavior component as a mere function. Compilation may not even be necessary.
This framing discredits source
, prelink
, unlink
, preinstantiated
, instantiable
, &c. But the verb describe suggests “descriptor”. This would look like:
import descriptor md from 'module';
await import.descriptor('module');
const m = new Module(md);
// or
const m = module {
import foo from 'bar';
};
// Can be extracted from a module instance
const { descriptor } = m;
// May reflect bindings and behavior
descriptor.bindings;
// could look like:
// [{ import: 'foo', from: 'bar' }]
descriptor.behavior;
// could look like:
// function (environment, meta, dynamicImport) {}
// Where available and relevant, could conceivably
// expose source code (this is not proposed, but would
// avoid a language wart like source.source.
descriptor.source;
// could look like:
// "import foo from 'bar';\n"
// Module system still needs to be expressly entered
// through dynamic import, and only language internals
// can create namespaces, environments (the module’s internal
// namespace), and meta objects.
await import(m);
from proposal-source-phase-imports.
I don't think this is bike-shedding; misnomers have real world dev-time cost and as a teacher I watch people trip over confusing JavaScript edgecases every day. It doesn't have to be perfect, but theres no going back and JavaScript isn't as simple as when you and I learned it. Good enough is good enough, but these current options are pretty bad.
Just as a sanity check we should ask ourselves if there is a "not" of a modifying keyword
const
implies there's a non-const (mutable)async
implies the default is synchronousimport parsed
... is the defaultimport
NOT parsed? no? Is there some other kind of import that isn't parsed? No? What???import source
. Is there some kind of import-but-without-the-source? Does the default import not import the source? What does that even mean?import instantiable
is marginally better (implying the default is non-instantiable), but we mostly agree, as a keyword, it is too unwieldy
Just as a viewpoint/context, we should sketch names for each stage; because each name should answer "how am I different from the other stages?"
import.resolve // verb (only resolving, not fetching) and its already named
import bytes // fetched, but nothing more
import string // decoded, but not more
import ast // I would assume parsed but nothing more
import detached // compiled but no attached context
import unlinked // attached
import unevaled // linked
Something like import detached
passes the negation test (e.g. "so normal imports are attached?" -> yes/obviously)
So, please consider the options below:
I'm not going to champion one, as I just want any good-enough solution and I think the 4 options above don't make the cut.
import detached <thing> from "source"
compile <thing> from "source"
Similar to import.resolve; the verb implies it's "merely" compiled and nothing moreimport as detached <thing> from "source"
import.compile <thing> from "source"
- `import binding from "source"
- `import partial from "source"
- `import skeleton from "source"
- Some other alternative!
from proposal-source-phase-imports.
the source of the imported module
I think the issue is it doesn't diffentiate from the other steps. E.g. importing as a string (the source code) also qualifies as "representation of the source of a module", and importing the AST also qualifies as "a represention of the source of a module". It's like import code
or import thing
those aren't false statements, they're just not distinct enough to mean anything to someone who doesn't pre-know what it's suppose to mean.
I think source also fails the synonym test:
Swapping "const" with a synonym like "frozen" or "fixed" still would make sense.
Swapping "source" with something like "origin" or "root" doesn't make sense (e.g. import origin { thing } from "somthing"
?)
from proposal-source-phase-imports.
To me “instantiable” seems like the only term so far that directly describes what makes it different, but I can understand why it’s unpopular. Are there other terms that could convey this without resorting to words that are misleadingly over-specific?
(@rbuckton’s “abstract” suggestion is a good example of one that’s not over-specific, though it might suffer from the opposite issue. Personally I think under-specific is better than over-specific, though, since under-specific at least doesn’t mislead.)
from proposal-source-phase-imports.
It's worth noting here that most JavaScript code will not use import source x from './x.js'
.
Rather, the code that does this will be deep in npm libraries that use WebAssembly, that code itself being JS wrapper code generated by WebAssembly tooling.
For JS virtualization users when we support it for JS (as the name intendeds), this will be used for mocking and the construction of virtual sandboxes. Eg, creating a shadow realm, then using a source import to pass the source into that realm and execute it there. In these workflows I think the term source
makes complete sense to the developer (an experienced JS developer knowingly doing virtualization work). So I don't think they would be confused by it.
In the rare case where a novice developer sees this it would either be: a) browsing library code (in which case, yes I agree it would likely be confusing until they full grok how it is being used by following the code paths) or b) a Wasm library that instructs usage via the import source
mechanism, in which case it would be a blind copy-and-paste.
Semantically we have put a lot of thought to the terminology in use, so there's fair good reason for the usage. So if this is just about learning perhaps the argument is that the novice user simply doesn't need to be concerned about it?
from proposal-source-phase-imports.
My stance:
instantiable
: too long and unwieldy. It's not a widely used word and likely to be mistyped frequently, especially by non native speakers.handle
: too generic. A handle could be an asset reflection, a handle on an instantiated module, or anything really.parsed
: easy to type and remember 👍 - but I'm not confident this will be a much better name for folks outside of compiler circles however, because they don't care about how modules are fetched and parsed. Usually the result of parsing is an AST: will users be confused that this does not return an AST (Reflect.parse
anyone?)compiled
: also easy to type and remember 👍 - more correct, because at least in the Wasm case you are parsing + compiling to get aWebAssembly.Module
. Probably this is exposing too much info about internals though, and will be confusing outside compiler circles. This at least clarifies that the result is not an AST, but a compiled program.
TBH, not super convinced by any of these so far.
from proposal-source-phase-imports.
Is there some kind of import-but-without-the-source? Does the default import not import the source? What does that even mean?
import source
gives you a representation of the source of the imported module. The default behavior does not do that, it gives you the result of evaluating the module. The modifier here is not describing the "internal process", but it's describing the result value.
from proposal-source-phase-imports.
I can live with parsed
or instantiable
, but given the general negative feedback to instantiable
, parsed
seems promising.
from proposal-source-phase-imports.
What about having one comment per option, that people can 👍 / 👎 ?
from proposal-source-phase-imports.
from proposal-source-phase-imports.
I might suggest: syntax
, coming from the Racket programming language. For Racket, syntax data is typically used in macros, but in a wider sense, syntax refers to a rich representation (it includes the source location, such as a URL or file path, along with line and column information) of not-yet-evaluated data, including whole modules.
from proposal-source-phase-imports.
Is syntax
an abstract syntax tree in racket?
from proposal-source-phase-imports.
“abstract” suggestion
to +1 on that; googling JavaScript import abstract
(or many of the other terms) will likely return relevant results in the future.
Googling JavaScript import source
is going to return all kinds of source-map results and irrelevant threads.
from proposal-source-phase-imports.
PSA My understanding is that we’re coming close to the deadline for the champions to make a decision of whether to run with source
or an alternative. Please review your votes before the deadline lapses. It doesn’t look to me like momentum has gathered around an alternative to source
and I’d like to at least give descriptor
a fair shake. #54
from proposal-source-phase-imports.
Is
syntax
an abstract syntax tree in racket?
Yes, in general it is. It could be a simple string that needs to be parsed later on, but typically it contains an AST.
from proposal-source-phase-imports.
Thanks everyone for the feedback and discussion. We have unfortunately not found a compelling alternative that has wider support than source
, as you can see in #54. As such, we'll be sticking with the import source
syntax.
from proposal-source-phase-imports.
Related Issues (20)
- Parameterized Evaluators HOT 3
- trusted type representation superceding asset references HOT 6
- Relationship to asset references proposal HOT 14
- Use extensible object syntax? HOT 68
- Use special module specifier format HOT 2
- Reflect string versus boolean HOT 2
- Lazy versus eager reflection HOT 2
- Reflect with transitive dependencies HOT 6
- Stage 3 reviews HOT 8
- Support both module reflection and module source reflection HOT 3
- Consider a method-like `import` metaproperty for source phase imports HOT 6
- Disallow newlines between phase and identifier HOT 1
- Consider cost of `import source from` ambiguity
- `export source x from "y"` HOT 4
- Missing sources should throw a *SyntaxError* when imported HOT 3
- Is %AbstractModuleSource% synchronously reachable from script? HOT 2
- Bikeshedding the `source` keyword: voting HOT 16
- WebAssembly compile-time imports HOT 7
- "Source" is a little confusing HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from proposal-source-phase-imports.