The place where the current syntax shines is when dealing with anonymous
values,
On Jun 25, 2014 1:29 AM, Barronville, Jonathan jonat...@belairlabs.com
wrote:
Kevin, you're not alone :) . I like that last form, too.
- Jonathan
—
Sent from Mailbox https://www.dropbox.com/mailbox
On Wed,
Le 25 juin 2014 à 11:16, Calvin Metcalf calvin.metc...@gmail.com a écrit :
The place where the current syntax shines is when dealing with anonymous
values,
For that case, the same sugar as named exports could work:
export let default = ...
at the condition to allow default as an
Thanks Kevin.
Back to bikeshedding import export syntax.
The refactoring hazards of defaulting to an object with all the exports are
going to depend on how the feature is described, talking in terms of
looking first for a default export and then returning the module body and
now you get
But if modules were said to have a default default export that was an
object with all the exports that could be overridden then that's different.
I see where you're coming from, and honestly I don't have a better argument
against a default default. (I actually tried to argue for that once
The
import 'foo'
let foo = this.get('foo')
Is less of a hassle if you only need it for when you have default and named
exports and need the module object.
On Jun 25, 2014 7:48 AM, Kevin Smith zenpars...@gmail.com wrote:
But if modules were said to have a default default export that
import 'foo'
let foo = this.get('foo')
Please no. Just...no.
: )
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Hi,
On Fri 20 Jun 2014 15:16, Mark S. Miller erig...@google.com writes:
On Fri, Jun 20, 2014 at 1:48 AM, Andy Wingo wi...@igalia.com wrote:
There is one change:
({ foo: 3, get foo() { return 4 } })
This is not allowed with current sloppy mode.
Yes, good catch.
On Wed 25 Jun 2014 15:19, Andy Wingo wi...@igalia.com writes:
Hi,
On Fri 20 Jun 2014 15:16, Mark S. Miller erig...@google.com writes:
On Fri, Jun 20, 2014 at 1:48 AM, Andy Wingo wi...@igalia.com wrote:
There is one change:
({ foo: 3, get foo() { return 4 } })
If I recall correctly the intent was that __proto__ was special syntax for
setting the [[Prototype]]. So only three following cases are setting the
[[Prototype]]
{__proto__: object}
{'__proto__': object}
{__proto__: object}
Other combinations set an own property:
{['__proto__']: object}
import 'foo'
let foo = this.get('foo')
To be less flippant, this isn't a solution to the problem: how do I
statically bind to a module instance object? It's a runtime workaround.
Default-default aside, what's the payoff in trying to obscure the fact that
a module is always a named
On Wed 25 Jun 2014 17:09, Erik Arvidsson erik.arvids...@gmail.com writes:
If I recall correctly the intent was that __proto__ was special syntax
for setting the [[Prototype]]. So only three following cases are setting
the [[Prototype]]
{__proto__: object}
{'__proto__': object}
{__proto__:
yes, this is covered by
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-__proto__-property-names-in-object-initializers
__proto__ only has special meaning within a production:
PropertyDefiniton : PropertyName : AssignmentExpression
and when PropertyName is not a
import 'foo'
let foo = this.get('foo')
that was what came out of the last meeting to replace module/from semantics
the payoff is decoupling how something is imported from how something is
exported. A module is a bag of names, but there is no reason an import has
to be as well.
On
From: es-discuss es-discuss-boun...@mozilla.org on behalf of Calvin Metcalf
calvin.metc...@gmail.com
the payoff is decoupling how something is imported from how something is
exported.
+1. Although I am uneasy about the default-default export idea, since it has
[several edge cases][1] that
Allen,
If propKey is the string value __proto__
Do we want to allow __\u0070roto__ or not? For use strict we made it
clear that no escape sequences are allowed. I think we should follow that
route unless it makes implementation and/or speccing too hard.
On Wed, Jun 25, 2014 at 11:21 AM, Allen
the payoff is decoupling how something is imported from how something is
exported.
Maybe I'm being dense, but I must admit I find this statement to be
completely baffling. The import side always has to match the export side -
how could it possibly be any different? What am I missing here?
On Wed, Jun 25, 2014 at 1:38 PM, Kevin Smith zenpars...@gmail.com wrote:
the payoff is decoupling how something is imported from how something is
exported.
Maybe I'm being dense, but I must admit I find this statement to be
completely baffling. The import side always has to match the
One import syntax. C'mon, we've been over this for *months* Kevin.
I get that, I really do. But specifically, that would mean a
default-default, right?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
default-default is the least worst one I have heard that doesn't totally
change everything,
On Wed, Jun 25, 2014 at 2:08 PM, Kevin Smith zenpars...@gmail.com wrote:
One import syntax. C'mon, we've been over this for *months* Kevin.
I get that, I really do. But specifically, that would
default-default is the least worst one I have heard that doesn't totally
change everything,
Fair enough. Thanks for putting up with my questioning - I think I have a
better understanding of where you and Scott are coming from now.
Correct me if I'm wrong, but the perspective says: why would
On Jun 25, 2014, at 10:27 AM, Erik Arvidsson wrote:
Allen,
If propKey is the string value __proto__
Do we want to allow __\u0070roto__ or not? For use strict we made it
clear that no escape sequences are allowed. I think we should follow that
route unless it makes implementation
On Wed, Jun 25, 2014 at 3:20 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
I think use strict is a special care where we were trying to simulate
what we would allow in a statement composed of reserved words and escapes
are now allowed in keywords.
On Wed, Jun 25, 2014 at 2:59 PM, Kevin Smith zenpars...@gmail.com wrote:
Correct me if I'm wrong, but the perspective says: why would I need to
import the multiple-exports if I'm specifically overriding the exports with
a default? Having a way to import both the default and multiple-exports
right, typo now- not
On Jun 25, 2014, at 12:36 PM, Erik Arvidsson wrote:
On Wed, Jun 25, 2014 at 3:20 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
I think use strict is a special care where we were trying to simulate what
we would allow in a statement composed of reserved words and
// I have a module named `foo`.
// I don't care what `foo` is.
// Including whether or not its a namespace.
// I need make no promises about identifier `foo`.
import {bar} from './foo';
On Wed, Jun 25, 2014 at 12:52 PM, C. Scott Ananian ecmascr...@cscott.net
wrote:
On Wed, Jun 25, 2014 at 2:59
@John Barton: Yes, ideally that syntax would work as well when you don't
need a namespace. But sometimes you do need a namespace, even if you don't
care precisely what it is:
```
import {format} from 'url';
import {format} from 'util';
import {connect} from 'tls';
import {connect} from 'net';
You don’t actually need a namespace for this, though it may be more
convenient/aesthetically pleasing than the alternative:
```
import {format as formatURL} from 'url';
import {format} from 'util';
import {connect as tlsConnect} from 'tls';
import {connect as netConnect} from 'net';
import {fork
On Wed, Jun 25, 2014 at 6:17 PM, Brian Donovan m...@brian-donovan.com wrote:
You don’t actually need a namespace for this, though it may be more
convenient/aesthetically pleasing than the alternative:
may? (!)
--scott
___
es-discuss mailing list
28 matches
Mail list logo
