joe wrote:
If we're going to have convenience multiples of PI, they should be a)
non-ideological, and b) include more than one (PI/2 comes up a lot in
vector math, for example).
Why not have:
Math.PI
Math.DPI //double pi
TAU
Math.HPI //half pi
ETA, conventionally.
Or perhaps we
So I think we've gone over the interoperability argument already. That is,
with default exports (or module-object-overwriting), you can write
something like this:
import x from some-old-module;
Without default exports, you'll have to use something like one of the
following:
import {
There are three arguments for default exports:
1. Anonymous exports are a value-adding feature, as it allows the user to
use a library without having to know the export name.
2. Default exports allow more streamlined renaming of the imported binding.
3. Default exports allow smoother
My recommendation is to drop the default export feature and leave
everything else as is (except perhaps for making module.x equivalent to x
per Andreas). Given that the current module system has far better support
for circular dependencies than module-as-module designs, the static
export design
My recommendation is to drop the default export feature and leave
everything else as is (except perhaps for making module.x equivalent to x
per Andreas). Given that the current module system has far better support
for circular dependencies than module-as-module designs, the static
export
If it had good enough support for circular dependencies, would we be able
to make sense of module-as-module designs?
Side note: I meant object-as-module really. It's kinda funny that I
capped off all of that with such a silly mistype. : )
___
one benefit of default exports is forcing people to choose one of
export { x as exports };
export { x as default };
export { x as _ };
this is the one chance to get everyone on the same page
as far as object-as-module having circular dependency issues, can you
elaborate on that, I
On Tue, Jul 1, 2014 at 1:36 PM, Calvin Metcalf calvin.metc...@gmail.com
wrote:
one benefit of default exports is forcing people to choose one of
export { x as exports };
export { x as default };
export { x as _ };
this is the one chance to get everyone on the same page
I
Can't proxies or getters/setters be used to get objects to behave like they
have named exports? As in, when getting a property of the object it looks
up the current value of the bound value in the module. I can't see why this
wouldn't work, but there is probably a reason since nobody has proposed
module name from './path'
...
name.method();
Right - that would work for objects-as-modules, but this wouldn't:
import { something } from ./path;
Unless you somehow emitted getters for all references to something.
Without consulting documentation, I would expect that these
From: es-discuss es-discuss-boun...@mozilla.org on behalf of C. Scott Ananian
ecmascr...@cscott.net
If we're cutting things from the ES6 module spec, can we consider cutting the
magical mutable `import {foo} from ./foo;` bindings as well? Experience
has shown that the rare cases where
If it had good enough support for circular dependencies, would we be able
to make sense of module-as-module designs?
OK, so let's assume for the sake of argument that objects-as-modules is
not confusing, so (4) doesn't apply. All of the arguments for and against
default exports also apply to
As such, we are balancing the marginal user experience gains of
export-overwriting against the better support for circular dependencies
of real modules.
Another way of looking at it:
Being in control of the language, you can always invent new sugar to
optimize user experience (within limits)
13 matches
Mail list logo
