On Oct 2, 2014, at 8:31 AM, Andreas Rossberg wrote:
> On 2 October 2014 17:17, Allen Wirfs-Brock wrote:
>> I believe that the module champions have always wanted static unresolvablse
>> reference rejection to be part of the module semantics. But we've never had
>> actual specification for tha
On Sep 30, 2014, at 4:03 AM, Andreas Rossberg wrote:
> On 30 September 2014 12:52, Jason Orendorff wrote:
>> I just realized this has an unfortunate implication for REPLs. Suppose
>> you make this typo:
>>
>>js> let x = Math.cso(a)// oops, TypeError, should be Math.cos
>>
>> Now x is i
On Aug 28, 2014, at 10:10 AM, Ian Hickson wrote:
> Here are the changes that would be needed to make the ES6 loader
> infrastructure underpin the Web platform's loader infrastructure
> (basically, placing the ES6 loader the management layer between the Web
> platform APIs on top, and Service W
On Aug 12, 2014, at 2:46 PM, Ian Hickson wrote:
> On Tue, 12 Aug 2014, David Herman wrote:
>>
>> This is part of the design work we're actively working on. I'd ask you
>> to hold off until we have some more information for you. I'll keep you
>> post
On Aug 12, 2014, at 2:05 PM, Ian Hickson wrote:
> Assume my script is http://example.com/test.js, and assume that there is
> no extra information (nobody has registered any module names or anything
> like that). If I do:
>
> import "a";
> import "./a";
> import "/a";
> import "//exampl
On Aug 11, 2014, at 5:06 PM, Ian Hickson wrote:
> So I'm trying to figure out how to spec the HTML spec's Loader.
We should coordinate -- I've been actively working on this (not the spec per
se, but the design) with people engaged in the JS modules work. The HTML
default loader design has some
On Jun 19, 2014, at 3:31 AM, Michał Gołębiowski wrote:
> Thanks, Dave, for bringing that up, it shows you're open for feedback. That
> said (bikeshed begins),
lol :)
> what's wrong with:
> ```js
> import "fs" as fs;
> ```
Indeed we've talked about that one before. Some objected to the inconsi
On Jun 19, 2014, at 2:03 AM, Axel Rauschmayer wrote:
> Does the proposed syntax clash with `export * FromClause` (which, I’m
> assuming, re-exports everything, not just the named exports)?
No inconsistency; it imports everything. Exactly the same semantics as always,
just a change in surface s
Thanks to everyone for working through the issues around ModuleImport. I know
it's been frustrating, but the discussions have really helped clarify the key
constraints.
## Constraints
First, let me restate the most important arguments. In favor of removal:
* **The syntactic distinction between
Your proposal is appealing but I haven't convinced myself it works. There are a
couple bits I haven't quite grokked.
> The special `constructor` method in ClassDeclaration/ClassExpression syntax
> would desugar to a static @@new method. This class:
>
>class Point {
>constructor(x = 0
On Jun 17, 2014, at 5:31 PM, Domenic Denicola
wrote:
>> Interesting questions in that thread about what to do about time zone
>> changes. An event for time zone changes seems important, but we don't
>> currently have any precedent for standard library events in ECMAScript.
>
> Object.observe
This was brought up on specifiction:
http://discourse.specifiction.org/t/navigator-timezone/152
Does anyone know why it was left out of the first version of the Intl API? Just
for lack of time? Is it planned for the next edition? Are there tricky issues
around standardizing IANA time zones,
On Apr 25, 2014, at 9:10 AM, Allen Wirfs-Brock wrote:
> People will write code like this if we allow it. But we don't have to allow.
> We can preserve the semantics of try-finally by simply making the occurrence
> of the 'yield' operator syntactically illegal within the try block of a
> try-
On Apr 29, 2014, at 12:17 PM, Domenic Denicola
wrote:
> Anyway, regardless of the specifics of my `using` proposal, I hope that
> highlighting the iterability vs. disposability aspects of this conversation
> was helpful to people.
I do think it's helpful for understanding the space, thanks.
On Apr 25, 2014, at 10:42 AM, Allen Wirfs-Brock wrote:
> Nope, it's always been designed this, going back to the original wiki
> strawman
> http://wiki.ecmascript.org/doku.php?id=harmony:destructuring#semantics and I
> assume the original FF implementation.
>
> It has also been something that
On Apr 29, 2014, at 12:40 AM, Andy Wingo wrote:
> I'm a bit grumpy that this is being brought up again, and
> this late, and in multiple forums, but as it seems that people want to
> talk about it again, that talking about it again is the thing to do...
Sorry about that. :( But the fact is Jafar
Sad panda. At least we can disable it in strict mode, right?
And who knows, maybe some day, some day...
Dave, dreaming of ES24
On Mar 13, 2014, at 4:59 PM, Oliver Hunt wrote:
> JSC has been trying to kill off the initialiser expression in the for(in)
> statement, but we've encountered a bunch
On Mar 14, 2014, at 10:50 AM, Russell Leggett wrote:
> I completely agree with this. It looks like a modifier.
This is a good point, and folks working on the Square transpiler noticed this,
too. I think there's a more surgical fix, though (and I'm not entertaining
major syntax redesign at this
On Mar 14, 2014, at 9:37 AM, Andrea Giammarchi
wrote:
> I like that more I read about this, more the `with` statement comes into my
> mind ...
There's nothing like this in JS today, so if you're only looking for precedent
there, you're only going to be able to come up with weak analogies. The
On Mar 14, 2014, at 9:27 AM, John Barton wrote:
> I've used es6 modules for several months now and I'm curious to know when I
> would want to leverage mutable bindings.
So cycles work!
// model.js
import View from "view";
export default class Model {
...
}
// view.
OK, we can discuss and report back. We'll definitely want to take into account
Guy's use case about being able to recognize module instance objects as such.
Dave
On Feb 21, 2014, at 12:53 PM, Allen Wirfs-Brock wrote:
>
> On Feb 21, 2014, at 12:08 PM, David Herman wrote:
no, it's in Reflect
Dave
On Feb 21, 2014, at 12:13 PM, Domenic Denicola
wrote:
> Is Module a global now?
>
> From: es-discuss on behalf of David Herman
>
> Sent: Friday, February 21, 2014 15:08
> To: Allen Wirfs-Brock
> Cc
I think it should be Module.isModule.
Dave
On Feb 21, 2014, at 10:57 AM, Allen Wirfs-Brock wrote:
> it's not going to be instanceof for various technical reasons.
>
> I suspect, we can have a isModule predicate function somewhere. Perhaps,
> Reflect.isModule or Reflect.Loader.isModule...
>
On Feb 14, 2014, at 12:09 PM, John Barton wrote:
> (There is no spec on "System", just rumors that it will be a predefined,
> global instance of Loader).
"Rumors" is a bit much. :) The notes do show the discussion but the resolution
for some reason didn't get recorded. IIRC there was agreement
On Feb 14, 2014, at 12:32 PM, C. Scott Ananian wrote:
> john: yes, I suspected that System was underspecified. That's too bad.
It's a separation of responsibilities. `System` is the point where the
ECMAScript language (core module system) meets the host environment
(filesystem/web browsers/et
On Feb 10, 2014, at 8:55 AM, John Barton wrote:
> Indeed, however, this herring is only red on one fin: the mutability of
> System is not limited to the registry and in fact every aspect of the System
> is mutable. As far as I can tell, a mutation to say normalize or locate is
> entirely unpre
On Feb 7, 2014, at 8:06 AM, John Barton wrote:
> The first goal listed for ecmascript modules:
> • Obviate need for globals
> (http://wiki.ecmascript.org/doku.php?id=harmony:modules).
> Ironically, the current proposal for module loading includes a global
> "System" and possibly "Loader".
On Jan 27, 2014, at 2:18 PM, Marius Gundersen wrote:
> So then there would be two versions of the same module, and a module could
> get access to both these modules at the same time. For example, if ModuleB,
> which depends on ModuleA is loaded and linked, and later ModuleA is
> redefined, the
Here are several ways to think about return:
- A generator function is like a normal function but it can be paused. The act
of pausing can send an intermediate value out to the caller (yield's argument)
and the caller can send an intermediate value back in when resuming (yield's
result). None o
[Resending, not sure why it's not getting through to the list...]
On Jan 27, 2014, at 10:41 AM, David Herman wrote:
> On Jan 27, 2014, at 2:07 AM, David Bruant wrote:
>
>> Indeed. I'm wondering why we need inline for modules.
>
> Because people write inlin
On Jan 27, 2014, at 2:07 AM, David Bruant wrote:
> Indeed. I'm wondering why we need inline for modules.
Because people write inline scripts all the time. It's unacceptably
inconvenient not to be able to bootstrap your app with inline code. It also
allows you to control for when the scripts r
On Jan 27, 2014, at 10:58 AM, David Bruant wrote:
> Agreed. Note that I didn't suggest to stop writing inline scripts and
> proposed an alternative to script@module that can work today.
> Granted, it's somewhat hacky, but I think it can work during the period
> during which there'll be both ES6
I'd like to suggest another sense in which you may have gone down a bad path:
you're assuming that await is paired with function*, but it could instead be
(like C#) paired with its own async-function syntactic form. Let's say for the
sake of argument that async is just a keyword that takes a fun
On Jan 23, 2014, at 4:49 PM, Brendan Eich wrote:
> Domenic Denicola wrote:
>> Task.js is still on "JavaScript1.8," and is not ES6-compatible. It won't
>> work with modern browsers, or with Regenerator.
>
> Fork and fix, should be easy. I expect a PR would be accepted in due course.
> SpiderMo
On Jan 6, 2014, at 8:10 AM, Brendan Eich wrote:
> To further constrain design (since design is mostly about leaving things
> out), I will address the ES4-era |let (x = y, z = z /* outer z*/) ...| let
> blocks and let expressions, which came up recently. We should not revive
> these, given do e
On Dec 20, 2013, at 5:32 AM, Andreas Rossberg wrote:
> For ES7 I would like to revive the do-expression proposal (hopefully
> at the next meeting)
Glad to hear you're in favor! I'll be happy to co-champion. The
const-initializer use case is a good one, but it's also extremely valuable for
code
On Dec 9, 2013, at 12:36 PM, Axel Rauschmayer wrote:
> What I’m worried about is conceptual simplicity. I like function declarations
> and prefer them to function expressions, but recently did a small survey on
> Twitter and was surprised to find out that the majority of people prefer var
> +
On Nov 28, 2013, at 12:25 AM, Axel Rauschmayer wrote:
> Source: David Herman,
> https://github.com/rwaldron/tc39-notes/blob/master/es6/2013-11/nov-20.md
>
> Can someone elaborate? I don’t see an alternative.
I can't remember the example I used in the meeting, but one exampl
On Nov 17, 2013, at 11:59 AM, Axel Rauschmayer wrote:
> On Nov 17, 2013, at 6:14 , David Herman wrote:
>
>>> Does this imply ?
>>
>> Works either way, inline or external. (Requiring src="" is one of the
>> reasons why
On Nov 16, 2013, at 7:54 AM, Matthew Robb wrote:
> Does this imply ?
Works either way, inline or external. (Requiring src="" is one of the reasons
why
On Nov 16, 2013, at 3:32 AM, John Barton wrote:
> Could someone help me understand why two goals for parsing JS is a good thing?
Hm, it sounds like you've assumed a conclusion already. Let me try to explain
anyway.
Scripts are for synchronous loading and evaluation; modules are for
asynchrono
IOW expose the first-class "reference type" of ECMA-262 via a standard library?
Just say no! :)
First, the module function API is written up wrong on the wiki; the function
won't take any arguments at all. My apologies, I discovered my mistake as I was
working on the spec writeup in the last fe
On Oct 25, 2013, at 7:49 PM, Allen Wirfs-Brock wrote:
> It turns out that even in pseudo code, this is a fairly complicated set of
> runtime validation rules to apply. I'm having a hard time convincing myself
> that the runtime computational and meta data costs of this dynamic validation
> is
On Oct 31, 2013, at 8:06 AM, Erik Arvidsson wrote:
> Make sense but I'm not sure it is needed/desired.
I agree, actually, despite being the one who put it in there in the first
place. I originally intended it as a convenience e.g. for quick scripts. But by
itself it's simply too brittle to wor
On Nov 1, 2013, at 6:19 PM, David Herman wrote:
> On Nov 1, 2013, at 7:44 AM, Jason Orendorff wrote:
>
>> Now... good use cases could be a sufficient counterargument to all
>> this. Maybe we should add `import * from` in 2014. I just want to make
>> it totally clear wh
On Nov 1, 2013, at 7:44 AM, Jason Orendorff wrote:
> Now... good use cases could be a sufficient counterargument to all
> this. Maybe we should add `import * from` in 2014. I just want to make
> it totally clear why it's designed this way for ES6. `import * from`
> poses significant problems, bot
On Oct 31, 2013, at 7:10 AM, Erik Arvidsson wrote:
> I see that Jason added a Loader.prototype.define to his reference
> implementation.
> https://people.mozilla.org/~jorendorff/js-loaders/Loader.html#section-177.
> This is great. It is a much needed capability to allow bundling modules into
On Oct 30, 2013, at 1:56 PM, Luke Wagner wrote:
> Just to be sure, do you agree that both the {lo, hi}-returning API and the
> magic-property API should both be able to achieve equivalent performance on a
> JS engine that has specifically added and optimized these int64 builtins? I
> think th
On Sep 27, 2013, at 12:05 PM, David Herman wrote:
>export const serialize = m ? m.serialize : new Symbol("friendly name");
And... of course I meant `Symbol()` rather than `new Symbol()`. Haven't
retrained my muscle memory from the days of the object-b
On Sep 27, 2013, at 10:14 AM, David Herman wrote:
> On Sep 27, 2013, at 10:02 AM, David Herman wrote:
>
>> - don't share symbols between workers
>
> Follow-up thought: it seems there are actually two concepts that both get
> grouped under "realms" and
On Sep 27, 2013, at 10:02 AM, David Herman wrote:
> - don't share symbols between workers
Follow-up thought: it seems there are actually two concepts that both get
grouped under "realms" and yet might warrant distinction. These correspond on
the web to two same-origin wind
On Sep 27, 2013, at 8:28 AM, Allen Wirfs-Brock wrote:
> On Sep 27, 2013, at 7:52 AM, Erik Arvidsson wrote:
>
>> What's the use case for Symbol.keyFor?
>>
>
> The use case was actually suggested in a response to dherman earlier in this
> thread when he mentioned sharing symbols between workers
On Sep 27, 2013, at 9:07 AM, David Bruant wrote:
> I agree with the intent of keeping semantics of inter-worker and
> inter-machine very close, but the difference in terms makes very clear that
> not being able to differenciate the 2 cases incurs an information loss that
> can be detrimental t
On Sep 26, 2013, at 7:01 PM, Kevin Smith wrote:
> - Enumerability? Yawn... Enumerability of user-created meta-level method
> names is fine and should be expected, just as we expect enumerability of
> "_"-prefixed method names today.
Whether you personally use it, for-in is a reality. Introsp
On Sep 26, 2013, at 5:03 PM, Allen Wirfs-Brock wrote:
> I meant, if you didn't have symbols you could pretty much do the same thing
> by exporting a name that is bound to the GUID string as its value. That
> exported name could be imported by clients and used as the friendly way to
> refer to
On Sep 26, 2013, at 4:43 PM, Allen Wirfs-Brock wrote:
> Right, this is the first instance registers pattern. You still need to use
> something like a GUID or naming convention to avoid accidental registration
> collisions.
Right, but the point is that you can abstract that away without it sho
On Sep 26, 2013, at 4:43 PM, David Herman wrote:
> On Sep 26, 2013, at 4:22 PM, Mark S. Miller wrote:
>
>> I am saying collision is an issue, but that it only seems that Symbols solve
>> it because we haven't yet designed the registry. So we should do so first,
>
On Sep 26, 2013, at 4:22 PM, Mark S. Miller wrote:
> I am saying collision is an issue, but that it only seems that Symbols solve
> it because we haven't yet designed the registry. So we should do so first,
> and then re-examine this question in the context of a concrete registry
> design.
I
On Sep 26, 2013, at 4:26 PM, Rick Waldron wrote:
> Thinking about this in terms of tooling, at even the terminal level, might
> look like this: http://gyazo.com/f61d0e25366ce7e526c79ab7fa77cb17.png
No no, the GUID doesn't go in user land objects. It only goes in the registry.
The user land obj
So let's assume there is such a registry. You can avoid accidental collisions
with the ugliest name in the universe -- gensym that thing to the n'th degree
-- but you're no longer forcing all clients to deal with the ugliness. You've
abstracted it behind your library. Let's say I'm implementing
On Sep 26, 2013, at 3:47 PM, Allen Wirfs-Brock wrote:
> Oh, that's not Hungarian notation, it's just a name space qualifier.
Don't talk down -- Rick was making a metaphor.
> But, if you assume that we will added a real private state mechanism into "ES
> 6.1" or "ES6.2" will Symbol really carry
On Sep 26, 2013, at 3:48 PM, Domenic Denicola
wrote:
> I don't understand why this is happening. There was fairly strong consensus
> on symbols at the last meeting, and nothing new has been brought to the
> table. Why are people's opinions suddenly changing? Vague fearmongering about
> "compl
On Sep 26, 2013, at 3:20 PM, Allen Wirfs-Brock wrote:
> Maybe the exception could be enumerability exception could be concise methods
> with string literal property names that do not parse as IdentifierName.
http://www.youtube.com/watch?v=VX4DJUr5oYg
Dave
_
On Sep 26, 2013, at 1:10 PM, François REMY
wrote:
>>> TLDR ==> The web needs a way to express executable code that does not rely
>>> on its parent context, is guaranteed to be side-effect-free, and can be
>>> executed safely anywhere (even in a different thread/worker/window/device,
>>> or as
On Sep 8, 2013, at 12:45 PM, Brendan Eich wrote:
> Erik Arvidsson wrote:
>>
>> Oh, I forgot about that wart.
>>
>
> Are default imports a wart no matter the syntax, or only because of this
> brace imposition issue you've identified? If the latter, perhaps there is
> another solution that giv
Axel wrote:
> The problem is that you have to bite the bullet of syntactic inconvenience
> for either default imports or normal imports.
Correct. This is the #1 justification.
Rick wrote:
> Subjectively, this is really hard to read, versus the curlies which provide a
> visual boundary (also s
On Aug 30, 2013, at 4:20 PM, Filip Pizlo wrote:
> This is the kind of weirdness that I hope struct types *don't* have, if their
> alleged purpose is to help people optimize their code.
This is a great point, thanks. On the one hand, I concluded long ago the
exposure of the buffer seems like so
On Aug 30, 2013, at 3:54 PM, Filip Pizlo wrote:
> Yup, that's what I was concerned about. And reading over the spec I agree.
> But just for sanity, we're guaranteeing this because you cannot create a
> struct type instance by pointing into an arbitrary offset of a buffer - you
> can only ins
On Aug 30, 2013, at 3:46 PM, David Herman wrote:
> E.g., if I have a struct type
>
>var T = new StructType({ a: t1, b: t2, ... });
>
> then for any given instance x of T, I know for sure that x.a and x.b do not
> alias the same storage.
(Except, of course, if t1 and t2
On Aug 30, 2013, at 12:46 PM, Filip Pizlo wrote:
> OK - by "sanepants" do you mean that there is no weirdo aliasing? Going back
> to my example of field 'a' aliasing field 'b' - is it possible?
There is plenty of aliasing possible, but I'm trying to understand what you
mean specifically by "w
On Aug 30, 2013, at 9:39 AM, Allen Wirfs-Brock wrote:
> I think the right-way to think about structs is as an record structure with
> no properties fixed behavior provided by a "wrapper". Very similar to the ES
> primitives except that structs can be mutable. The way to associate
> propertie
On Aug 27, 2013, at 9:47 AM, Filip Pizlo wrote:
> I do. Placing named properties on arrays makes sense. Consider a matrix
> implemented as a Float32Array, with named properties telling you the numRows
> and numCols. Just one example.
There are of course other ways to achieve this that don't i
In Lisp it makes sense to allow binding keywords because there's no such thing
as a keyword: once you bind it, it's a variable and you can refer to it. In JS
it's impossible to refer to it as a variable so it's just an (un)attractive
nuisance.
The only place where I could see this being arguabl
On Aug 21, 2013, at 2:36 PM, Brendan Eich wrote:
> David Herman wrote:
>> Any, String and Object should still be uppercase. The naming convention is:
>> value types lowercase, reference types uppercase.
>
> Is String really a reference type? Currently you can't tell
On Aug 21, 2013, at 12:49 PM, Dmitry Lomov wrote:
> I really hope that uint64 from value type spec and uint64 from typed object
> spec are one and same thing (we now in typed objects spec allow using
> uint8/uint16/.. &co to be used as conversion functions).
Agreed, and my feeling is that for
>
>
> On Wed, Aug 21, 2013 at 9:02 PM, David Herman wrote:
> Any, String and Object should still be uppercase. The naming convention is:
> value types lowercase, reference types uppercase.
>
> Dave
>
> On Aug 21, 2013, at 4:21 AM, Dmitry Lomov wrote:
>
> &g
If necessary, i.e. if people want to release it before modules, we can make it
available in a single top-level object, but I would not at all favor dumping
everything onto the global scope.
Dave
On Aug 21, 2013, at 12:07 PM, David Herman wrote:
> The intention has always been for them to
te code that does absolutely
> nothing (for performance reason) but will look like the real thing so I can
> start experimenting with static structures and possibly a develop VS
> production version of an ES3 to ES5 compatible polyfill since I believe your
> code won't run
where except in SpiderMonkey (which is OK but it's not
> suitable for a lightweight migration to "structure like" logic)
>
> Thanks.
>
>
> On Tue, Aug 20, 2013 at 4:55 PM, Andrea Giammarchi
> wrote:
> Awesome, thanks!
>
>
>
On Aug 20, 2013, at 1:31 PM, Andrea Giammarchi
wrote:
> [In this page](http://wiki.ecmascript.org/doku.php?id=harmony:typed_objects),
> and in the latest meeting note too, I can read both uint8 and Uint8, as
> example.
Bug. Fixed, thanks.
> **The Question**
> How is `new StructType({x:Uint32
On Aug 15, 2013, at 9:27 PM, David Herman wrote:
> we couldn't really come to any conclusions without Brendan and Andreas there
My mistake, Brendan was there. It was only Andreas who wasn't there.
Dave
___
es-discuss mailing li
On Aug 14, 2013, at 9:54 AM, Dmitry Soshnikov
wrote:
> throws
>
> to bind to undefined you would say:
>
> var {p=undefined} = {};
>
>
> OK, so it's turned out to be refutable nevertheless.
This is *not* what I remember of the conversation, at all.
My understanding was that pretty much ever
On Aug 12, 2013, at 6:32 PM, David Bruant wrote:
> How do people recover today from when the user click "stop script"?
They don't; it's a crash -- the web equivalent of "this application has stopped
responding." You might as well ask for a solution to the halting problem! :)
Dave
On Aug 12, 2013, at 5:43 PM, David Bruant wrote:
>> - I see *no* reasonable alternative to runaway microtask churn other than
>> slow-script dialog.
> So did Dominic [1]. I suggested something else [2] and he found the idea
> interesting. What do you think?
Quoting you from
> [2] https://mail
On Aug 12, 2013, at 5:40 PM, François REMY
wrote:
> I don't think of you as unimaginative, but I think there are other options.
:)
> Sure, there must be a way to "kill" a script that's burning your CPU but it
> doesn't have to be a dialog.
That's fine, I guess I didn't really mean dialog box
On Aug 4, 2013, at 8:01 AM, Axel Rauschmayer wrote:
> My guess: if you re-export something from a module, then you still have to
> import it if you want to use it in that module. Is that correct?
Correct.
> Examples of re-exporting:
>
> export * from "crypto";// re-exp
On Aug 8, 2013, at 2:08 PM, K. Gadd wrote:
> Why is the slow script dialog box even relevant for setImmediate? As I
> understand it, setImmediate is equivalent to DoEvents in Visual Basic/Windows
> Forms and pumping the message loop in a normal C application. That is, you
> can use setImmediat
On Aug 8, 2013, at 7:09 AM, Anne van Kesteren wrote:
> On Thu, Aug 8, 2013 at 3:03 PM, Domenic Denicola
> wrote:
>> To me the answer always seemed obvious: use the slow-script dialog. What am
>> I missing?
>
> That seems like a bad answer. Slow-script dialogs are a misfeature.
> They only exis
On Jun 6, 2013, at 11:05 AM, Axel Rauschmayer wrote:
> OK, so you don’t want to replace
>
> import foo from "single_export_module";
>
> with (braceless!)
>
> import default as foo from "single_export_module";
That's correct, I don't want to use `import default`.
Dave
___
On Jun 5, 2013, at 2:58 PM, Domenic Denicola
wrote:
> From: David Herman [dher...@mozilla.com]
>
>> Moreover, Yehuda has urged me to consider
>>
>> export x = 17;
>>
>> as sugar for
>>
>> export let x = 17;
>
> I'd urge `con
On Jun 5, 2013, at 3:59 PM, Axel Rauschmayer wrote:
> This makes a lot of sense. It would obviate the need for braces, right?
No, at least not for imports. This is only about exports. I'd argue we should
keep the braces on export { x, y, z } for symmetry with imports.
Dave
___
On Jun 5, 2013, at 11:51 AM, Kevin Smith wrote:
> It occurs to me that this is valid under the current grammar:
>
> import { default as foo } from "foo";
> export { foo as default };
>
> We've discussed using a well-known symbol for the default export, but this
> simple desugaring migh
On Jun 4, 2013, at 6:31 AM, Kevin Smith wrote:
> Looks good, but I'm thinking that this should probably _not_ be allowed:
>
> import {,} from "x";
Right you are! Fixed, thanks.
Dave
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail
On Jun 3, 2013, at 12:24 AM, Domenic Denicola
wrote:
> Ah, that makes sense! It's a nice way of prohibiting `export function
> foo() { }` as well, assuming inline `
On Jun 3, 2013, at 9:33 AM, Yehuda Katz wrote:
> On Mon, Jun 3, 2013 at 12:24 AM, Domenic Denicola
> wrote:
> From: sam...@gmail.com [mailto:sam...@gmail.com] On Behalf Of Sam
> Tobin-Hochstadt
>
> > I would just write `import {} from "someModule";`
>
> That appears to be disallowed; I belie
On Jun 3, 2013, at 10:29 AM, Axel Rauschmayer wrote:
> Bikeshedding:
Well, here comes a fun thread...
> Rationale:
> – Reducing the grawlix factor.
> – Making non-default imports more convenient – which I assume will happen
> more often(?)
That's what this comes down to: do you expect the com
On Jun 3, 2013, at 1:55 PM, Juan Ignacio Dopazo wrote:
> Now that it's been decided that braces are not a form of destructuring and
> the colon replaced with `as`, what's the benefit of using braces? Why not
> this previous proposal?
>
> import foo as foofoo from "foo";
>
> import "bar" as ba
On May 9, 2013, at 6:30 AM, Andreas Rossberg wrote:
> In your scheme, I honestly cannot tell. Which ones are absolute
> logical module names, which ones are relative logical module names,
> and which ones are relative URLs?
I realized I left this sub-thread hanging. While I think you've overstat
On May 15, 2013, at 10:42 AM, Andreas Rossberg wrote:
> (1) Change the set-up of .ondemand calls.
> (2) Change the invocation of your bundling tool.
>
> As soon as you have to go there, you've lost almost all advantages of
> the ID-based declaration form. Its assumed convenience doesn't scale
>
On May 13, 2013, at 4:15 PM, David Herman wrote:
> On May 13, 2013, at 11:07 AM, Allen Wirfs-Brock wrote:
>
>> It closes down this whole edge-case focused discussion and that's valuable
>> in itself. Also, since it turns try {yield expr} finally{} into a syntax
>
1 - 100 of 760 matches
Mail list logo
