Re: Proposal: anaphoric if and while syntax
For what it's worth, I'm on the side of people that do not want to see
assignment statements in control structures. I don't think it is necessary
and it results in code that is harder to read.
On Wed, Sep 14, 2016 at 8:51 PM, Alan Johnson wrote:
> What about `else if`?
>
> On Sep 14, 2016 9:28 PM, "Bergi" wrote:
>
>> Danielle McLean wrote:
>>
>> variables declared
>>> using `let` or `const` would be scoped to the individual `if` or `while`
>>> statement, rather than the containing block. In other words, the above
>>> syntax
>>> would be equivalent to the following currently-valid form I ended up
>>> writing:
>>>
>>> {
>>> const oldValue = _.get(object, 'some.long.path');
>>> if (oldValue) object.some.long.path = transform(oldValue);
>>> }
>>>
>>
>> What about `else` blocks, would the variables be available in them as
>> well?
>>
>> - Bergi
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
--
R. Mark Volkmann
Object Computing, Inc.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Existential Operator / Null Propagation Operator
I think the point is that people would like to write something like this: if (person?.address?.zipcode) instead of this: if (person && person.address && person.address.zipcode) That appeals to me. On Thu, Oct 13, 2016 at 12:20 PM, Bob Myers wrote: > Why is this needed? Why are people trying to get the property of an object > which is null? Why is the object null in the first place? This can probably > be considered poor program design. It's sort of like trying to dereference > a null pointer. In addition, parameter defaults and defaults in > destructuring may make this somewhat less of an issue. > > Note that TS2 is explicitly moving away from permitting null to be > assigned to something which is alleged to be an object. (Although TS2 has > "stolen" the `!` operator, it is merely a type assertion--a narrowing from > `object | null` to `object` as I understand it. It is not a run-time check.) > > But let's say we nevertheless think this is an important feature. It has > been discussed at great length here. No proposal has ever had the > inevitability, generality, or intuitiveness that would allow it to gain > traction. All the proposals are essentially little syntactic hacks. > > Can we find some more general extension to JS syntax that solves or > mitigates this problem as well as others? Kills two birds with one stone? > One that seems like a natural extension to current syntax, instead of an > extra magic character we stick somewhere to solve one specific problem? > > Just as an example, consider the following idiom for null propagation: > > ``` > a ? a.b ? a.b.c : undefined : undefined > ``` > > We can leverage this pattern by allowing the `:` in the ternary operator > to be omitted (defaulting to undefined), allowing us to write: > > ``` > a ? a.b ? a.b.c > ``` > > Whether you love it or hate it, at least this solves more problems that > just null propagation. I'm not seriously suggesting this. I'm just saying > we need to be more creative in brainstorming possible solutions to the > problem. > > -- > Bob > > > On Thu, Oct 13, 2016 at 9:37 PM, Claude Pache > wrote: > >> >> Le 13 oct. 2016 à 17:14, Kagami Rosylight a >> écrit : >> >> >> >IIRC the proposed syntax for computed properties was x?.[y], >> >> Yes you’re right, sorry :/ >> >> IMO it still seems the syntax problem is the main reason why this >> proposal has stalled. If not, what is the problem here? >> >> >> The issue with `?.[` is that it is considered as not pretty by some >> people. A syntax that is at the same time pretty, technically working, and >> not confusing is difficult to find. >> >> Concerning your suggestion of using `!`: From a technical point of view, >> using `![` instead of `?.[` may work only if you forbid a line terminator >> before the `!`, because the following program is valid as of today (with >> implied semicolons): >> >> ```js >> foo >> ![42] >> ``` >> >> I’m curious why this proposal is not even listed in stage 0 proposal list. >> >> >> Because no representative of TC39 has volunteered to champion it. >> >> —Claude >> >> >> ___ >> es-discuss mailing list >> es-discuss@mozilla.org >> https://mail.mozilla.org/listinfo/es-discuss >> >> > > ___ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > > -- R. Mark Volkmann Object Computing, Inc. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: .sort strange behavior
By default sort converts the values to strings and compares there Unicode values. For example, 10 would come before 3. In the first example you are overriding the default sort comparison in a way that is correct for numbers. --- R. Mark Volkmann Object Computing, Inc. > On Oct 21, 2017, at 7:57 AM, Cyril Auburtin wrote: > > ```js > [0,1,3,4,7,8,8,9,13,17,22,23,26].concat([16,19,21,22,25,32]).sort((a,b)=>a-b) > // [ 0, 1, 3, 4, 7, 8, 8, 9, 13, 16, 17, 19, 21, 22, 22, 23, 25, 26, 32 ] > > [0,1,3,4,7,8,8,9,13,17,22,23,26].concat([16,19,21,22,25,32]).sort() > // [ 0, 1, 13, 16, 17, 19, 21, 22, 22, 23, 25, 26, 3, 32, 4, 7, 8, 8, 9 ] > ``` > In the second case, it produces a weirdly sorted array, on node 8, chrome or > firefox > > What could explain this? > ___ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Proposal: Optional Static Typing (Part 3)
; > > From a quick read, I'm more in favor of something that's a little >> more restricted to start, something like what Python has. Python has >> optional static type annotations, but the Python interpreter just ignores >> them. They are present purely for the purposes of tooling, and are silently >> ignored at runtime. >> > >> > The goal with this proposal is to get essentially native hardware types >> where applicable. All the proposed types have special operator rules, value >> ranges (overflow behavior), and in the case of SIMD very real performance >> impact behind them. While documentation hints are a side-effect, I'm more >> focused instead for pushing ECMAScript toward being a more powerful >> language. Python is a classic example of where data type shortcomings lead >> to unintuitiveness or weird design like: https://docs.python.org/2/libr >> ary/array.html I'm trying to avoid such things. >> > >> > > One of the reasons why I'd prefer a simpler approach to start is that >> TypeScript and Flow, the two main implementations that add syntax, have a >> *very* similar syntax, but have several nuances that would make a heavier >> proposal much harder to accomplish: >> > >> > > - Flow has `?Foo` for optional types, TypeScript just uses unions. >> > >> > I have a section on unions with a small explanation on why I left it >> out. I kept it simple by only adding nullable types. Right now someone >> would overload or use 'any'. >> > >> > > - TypeScript has mapped/index types, where Flow uses special named >> types. >> > >> > I didn't include these. >> > >> > > - Flow allows omitted parameter names in function types, TypeScript >> only allows named parameters with implicit `any` types. >> > >> > I created an issue to be more explicit about optional and default typed >> parameters and the behavior. >> > >> > > - Flow has exact types, TypeScript doesn't. >> > >> > I hadn't even considered something like this. It sounds interesting for >> configuration options. They introduce new tokens. Something I'm very much >> avoiding for this initial proposal. >> > >> > > - Flow has `opaque type`, TypeScript only has `type`. >> > >> > Something to be decided later. Doesn't create breaking changes to add >> later. >> > >> > > - Flow constrains with `T: Super`, TypeScript uses `T extends Super`. >> > >> > There's a section on generics and why it isn't included already. I'm >> with you that it's far too complex to add in with initial types. There's no >> breaking changes introduced by adding it later. (Mostly because it >> introduces new tokens which would be a huge deal). >> > >> > > - Flow has existential types, TypeScript doesn't. >> > >> > I definitely haven't included this. Flow is a few steps ahead of this >> proposal. >> > >> > It seems like a lot of these features already aren't included in the >> proposal. I definitely hold your view that the proposal has to be minimal, >> but I think my minimal is functionally minimal. Something that when >> implemented allows developers to experiment and then discussion can >> progress from there to how more features can be added. I'm trying to be >> thourough though as to not harm a future proposal so if any of my decisions >> block something I'm open to changes. >> > >> > Most of my thoughts and focus have been on what I think of as the >> basics. How types interact with declarations, functions, classes, >> destructuring, allocation, and control structures. The future consideration >> sections are mostly a catalogue of ensuring that these basic initial >> features and designs will work as the language incorporates other proposals. >> > ___ >> > es-discuss mailing list >> > es-discuss@mozilla.org >> > https://mail.mozilla.org/listinfo/es-discuss >> ___ >> es-discuss mailing list >> es-discuss@mozilla.org >> https://mail.mozilla.org/listinfo/es-discuss >> > > > > ___ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > > -- R. Mark Volkmann Object Computing, Inc. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: es-discuss Digest, Vol 131, Issue 16
If optional types in JS were implemented like they are in Flow, the types would
be stripped before runtime. There are only there for pre-runtime type checking.
So nothing related to optimization would change and there would be no runtime
type checking.
---
R. Mark Volkmann
Object Computing, Inc.
> On Jan 13, 2018, at 5:27 PM, Ranando King wrote:
>
> Just throwing in my 2 cents.
>
> I would argue that this represents such a fundamental change to how the
> language works, that it would actually represent a new language, even though
> they're optional. One problem is in how this would be implemented. Making
> types optional introduces a lot of overhead in type checking. Such checks
> would have to occur at runtime since ES is a language capable of
> self-modification. What's more is that the weight of all these checks
> happening at runtime would cause a serious performance penalty to run speed.
>
> On the flip side, ```class``` already provides some of what you want to do.
> The proposal for private fields brings class even closer. If decorators are
> allowed to be applied to both non-objects and function parameters, then
> decorators could be used to close the gap. All that would be needed is to
> define a decorator for each desired type. The decorators would take care of
> the type checks while performing the documentation purposes you're saying
> would be one of the biggest features.
>
> Having used many typed languages before, I cannot deny the usefulness of
> types. However, where Javascript is concerned, mixing typed and untyped
> variables leads to complexities that could be flatly impossible to optimize.
> Have you considered what would happen if someone does something like this:
>
> ```javascript
> function doSomething(param: int32) {
>//Do something here
> }
>
> var a = 32;
> doSomething(a);
> a = "foo";
> doSomething(a);
> ```
> The engine would not be able to optimize this... ever. Every call would
> involve a type check before the call is made since the type of the parameter
> cannot be guaranteed to be converted to an int32. The engine would either
> need to disallow such a call from an untyped value, or type check every time.
>
> If you can imagine implementing types as syntactic sugar over what can
> already be done in ES6 (maybe with the inclusion of ES7 or proposed features)
> you might find a bit less push-back.
>
>
>> On Sat, Jan 13, 2018 at 3:43 PM, wrote:
>> Send es-discuss mailing list submissions to
>> es-discuss@mozilla.org
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>> https://mail.mozilla.org/listinfo/es-discuss
>> or, via email, send a message with subject or body 'help' to
>> es-discuss-requ...@mozilla.org
>>
>> You can reach the person managing the list at
>> es-discuss-ow...@mozilla.org
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of es-discuss digest..."
>>
>> Today's Topics:
>>
>>1. Re: Proposal: Optional Static Typing (Part 3) (Mark Volkmann)
>>
>>
>> -- Forwarded message --
>> From: Mark Volkmann
>> To: kai zhu
>> Cc: Brandon Andrews , es-discuss
>>
>> Bcc:
>> Date: Sat, 13 Jan 2018 15:43:52 -0600
>> Subject: Re: Proposal: Optional Static Typing (Part 3)
>> Not sure if this is the place to debate whether optional type support in
>> JavaScript would be a good thing, but I'll throw in my perspective. I used
>> to be anti-types. Then I decided to give Flow a try. Initially it felt like
>> I was spending a lot of time just learning the syntax and trying to make
>> Flow happy. But after a few weeks I caught on and noticed that every time
>> Flow complained it was actually correct. Then I needed to so some
>> refactoring. That's where the big benefit is for me. I no longer have to
>> manually determine what would break if I want to do things like change a
>> function name, change a property name in an object, and much more. I just
>> make the change and Flow tells me where I need to make adjustments. So
>> whether JavaScript adds types, I don't think I'll go back to not having
>> them. I'd much rather use Flow or TypeScript than not have types at all.
>>
>> On Sat, Jan 13, 2018 at 2:45 PM, kai zhu wrote:
>>>> I really don't understand the irrational aversion to OST or classes in ES.
>>>> If you don't want to use them, well don't use them. These features makes
>>>> sense for a lot of pr
Re: es-discuss Digest, Vol 131, Issue 16
That is why we have the websites definitelytyped.org and https://github.com/flowtype/flow-typed. Sure they don’t have type definitions for all libraries, but more are being added all the time and developers can provide their own definitions to fill in the gaps. Being able to use types, even when some libraries do not have type definitions is still far better than not using types at all. --- R. Mark Volkmann Object Computing, Inc. > On Jan 13, 2018, at 9:49 PM, Ranando King wrote: > > Stripping the types does solve the runtime problem, but only at the cost of > creating another. Suppose a website imported a remote library with types in > it. There's no way that, with the types stripped at runtime, the remote > library and the local code could validate that each other were satisfying > their type requirements. That is a major issue. The simple process of > modularization reduces the usefulness of types that are stripped at runtime > to only validating the self-consistency of each individual module. Good unit > testing can already do that. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Re: ES6 iteration over object values
What happened to adding the Object.values and Object.entries methods? There was some discussion that led me to believe these would be in ES6. Are they now targeted for ES7? -- R. Mark Volkmann Object Computing, Inc. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
what makes a file a module?
I understand that module code is implicitly in strict mode. In an ES6 environment, what causes a .js file to be treated as a module? Does that happen automatically to all files that export at least one thing? -- R. Mark Volkmann Object Computing, Inc. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: what makes a file a module?
On Sun, Oct 19, 2014 at 4:23 PM, Allen Wirfs-Brock wrote: > > It is implementation dependent how it is determined whether an individual > file will be parsed as a Script or as a Module. > This seems problematic because it means I can't assume that strict mode will be inferred. That may lead people to always specify it with 'use strict'. I was hoping to not have to do that. -- R. Mark Volkmann Object Computing, Inc. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: what makes a file a module?
Can we say anything more concrete if we restrict the discussion to modern browsers as opposed to non-browser ES engines? Is it fair to say that in those environments a file will always be treated as a module if it is imported by another file that the browser has loaded? On Sun, Oct 19, 2014 at 4:47 PM, Allen Wirfs-Brock wrote: > > On Oct 19, 2014, at 2:28 PM, Mark Volkmann wrote: > > On Sun, Oct 19, 2014 at 4:23 PM, Allen Wirfs-Brock > wrote: > >> >> It is implementation dependent how it is determined whether an individual >> file will be parsed as a Script or as a Module. >> > > This seems problematic because it means I can't assume that strict mode > will be inferred. That may lead people to always specify it with 'use > strict'. I was hoping to not have to do that. > > > It's not intended to be inferred. In fact, it can't necessarily be > inferred from the source code of a module or script. The intent is that the > designation of a source file as containing a module or script unambiguously > communicated to the ES engine. It is the manner in which that is > communicated which is be implementation or host environment determined. > > Allen > > > -- R. Mark Volkmann Object Computing, Inc. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Map: filter/map and more
Where can I read about the rationale to not put those methods on the Map
prototype? I'm curious why that was okay for the Array class, but not okay
for Map and Set.
On Thu, Nov 20, 2014 at 12:32 PM, Axel Rauschmayer wrote:
> At the meeting it was decided not to go with `map` and `filter` sitting on
> `Map.prototype`, but instead to use iterators in the way like:
>
> ```
> map
> .entries() // returns an iterator
> .map((v, k, m) => { ... })
> .filter((v, k, m) => { ... })
> .collect(); // returns a new map after all transforms
> ```
>
>
> Convenient, but this pattern couldn’t be extended to new Map classes or
> other collections. I see two alternatives.
>
> First, use the `Map` constructor. I don’t find this too bad and it’s
> self-explanatory.
>
> ```js
> new Map(map
> .entries() // returns an iterator
> .map((v, k, m) => { ... })
> .filter((v, k, m) => { ... }));
> ```
>
> Second:
>
> ```js
> map
> .entries() // returns an iterator
> .map((v, k, m) => { ... })
> .filter((v, k, m) => { ... })
> .collectInto(new Map());
> ```
>
> `collectInto(coll)` invokes `coll.set(k,v)` for each pair `[k,v]` in the
> sequence. It returns `coll`.
>
> --
> Dr. Axel Rauschmayer
> a...@rauschma.de
> rauschma.de
>
>
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
--
R. Mark Volkmann
Object Computing, Inc.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
iterating through object property values
It seems the typical way to do this is:
Object.keys(myObj).forEach(key => {
let value = myObj[key];
// Do something with value and/or key.
});
I don't see a new way to do this in ES6.
Is it still being considered to add the methods "entries" and "values" to
Object that return iterators?
--
R. Mark Volkmann
Object Computing, Inc.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
generator libraries
Many months ago I ran across a couple of libraries containing utility functions for working with generators. I recall one was a "take" function that was used to take only the first n values from a a given generator. I'm having trouble locating those libraries now. I think one of them was written by a TC39 member. Can anyone point me to a library like that? -- R. Mark Volkmann Object Computing, Inc. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Fwd: (x) => {foo: bar}
In addition, I don't think Traceur supports that syntax yet. I have had to
do this instead:
let f = x => {
return {foo: bar};
};
__ __
/ \/ \
\ /ark
Object Computing, Inc.
\ /olkmann
\/
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: (x) => {foo: bar}
My apologies. I meant to say that Traceur doesn't support returning a
literal object from an arrow function with syntax like this:
let f = x => ({foo: bar});
However, I just tested it again and it works fine. I could swear this
didn't work a few months ago. Maybe it was fixed recently. I'm happy!
On Mon, Jan 5, 2015 at 2:48 PM, Mark Volkmann
wrote:
> In addition, I don't think Traceur supports that syntax yet. I have had to
> do this instead:
>
> let f = x => {
> return {foo: bar};
> };
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Set.prototype.entries: indices as keys?
+1 --- R. Mark Volkmann Object Computing, Inc. > On Jan 18, 2015, at 6:28 AM, Axel Rauschmayer wrote: > > Currently the keys of the entries returned by `Set.prototype.entries()` are > the same as the values: > > ```js > let set = new Set(['a', 'b']); > > let pairs = [...set.entries()]; > console.log(JSON.stringify(pairs)); // [["a","a"],["b","b”]] > ``` > > Given that sets are ordered, I’d use the “position” of an entry as the key: > [[0,"a"],[1,"b”]] > > Rationale: First, having an indices as keys makes the entries more useful. > Second, destructuring already treats entries as if they had indices: > > ```js > let [x,y] = set; // x='a'; y='b’; > ``` > > -- > Dr. Axel Rauschmayer > a...@rauschma.de > rauschma.de > > > > ___ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: A new ES6 draft is available
Maybe this is wrong, but I'm in the habit of thinking that if something has a value of null, something in JavaScript code (mine or a library I'm using) explicitly set it to null. If something has a value of undefined, it was never set. For that reason, I'd prefer using undefined in this case over null. __ __ / \/ \ \ /ark Object Computing, Inc. \ / \/olkmann On Mon, Jan 19, 2015 at 10:54 AM, Allen Wirfs-Brock wrote: > > On Jan 19, 2015, at 5:51 AM, Claude Pache wrote: > > > Le 19 janv. 2015 à 11:58, Andreas Rossberg a écrit : > > On 17 January 2015 at 19:14, Allen Wirfs-Brock > wrote: > >> On Jan 17, 2015, at 9:53 AM, Domenic Denicola wrote: >> > On Jan 17, 2015, at 12:31, Allen Wirfs-Brock >> wrote: >> >> >> >> If the enclosing function is invoked as a call expression the value >> of `new.target` is null >> > >> > Just curious, why null instead of undefined? >> >> null is used to indicate no [[Prototype]], so it seem to me to be a >> better match for this situation. >> > > Wouldn't the fact that null is a quasi-legal prototype strongly speak for > using undefined here? Otherwise, it seems you couldn't distinguish Call > invocations from Construct invocations with a prototype that has actually > been set to null (which I suppose is legal?). > > (In terms of proper option/maybe types, this is yet another case of a None > vs Some(None) distinction.) > > /Andreas > > > `new.target` is a reference to the constructor, not the prototype, so the > problem does not arise in practice. > > But anyhow, I do think that `undefined` is semantically better here: > > * `new.target === null` means: `new.target` has been set to "no object". > * `new.target === undefined` means: `new.target` has not been set. > > > At the JS level, I don't actually think about `new.target` as something > that is "settable". I think about it as an oracle that tells me about how > this function was invoked. null means it was invoked "as a function". > non-null means it was invoked as a constructor and the value is the object > that `new` was applied to. > > > When you execute a function body with the semantics of [[Construct]], the > value of `new.target` is the original constructor on which `new` was > applied. If it was possible to have the semantics of [[Construct]] with no > original constructor, then `new.target` would be `null` (no-object). > > > But it isn't. Reflect.construct ensures that an non-null value is passed > to [[Construct]] as its second argument > > > But when you execute a function body with the semantics of [[Call]], there > is no notion of "original constructor", and `new.target` is left with no > value, i.e. `undefined`. > > > I originally intended `new.target` to use `undefined` is the sentinel > value to indicated "called as a function". But as I wrote the spec. it > felt better to use `null` in that role. I think it's because using `null` > seems more special. `undefined` is used in so many places to indicated so > many different things that it is hard to apply any generalized meaning to > it. On the other hand, `null` is used in only a few places in the ES spec. > so its use seems to draw attention to the specialness of those situations. > > But, I'd have no problem with changing back to `undefined` if there is a > consensus in favor of that. > > It really makes very little difference as `null` and `undefined` are both > falsey values, so the preferred way to write a "called as a function" these > should probably be: > > `if (! new.target) ...` > > Allen > > > ___ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > > ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: JavaScript 2015?
I do the same as Kevin. --- R. Mark Volkmann Object Computing, Inc. > On Jan 22, 2015, at 4:51 PM, Kevin Smith wrote: > > FWIW, here's the rule of thumb that I tend to use: > > - When referring to the language in general, it's Javascript or JS. > - When referring to a specific version of the language, it's ESx (e.g. ES5, > ES6, ES7). > - When referring to the specification itself (e.g. in proposals), it's > ECMAScript. > > >> On Thu, Jan 22, 2015 at 4:07 PM, Axel Rauschmayer wrote: >> I’m in the process of coming up with a good title for a book on ECMAScript >> 6. That begs the question: What is the best way to refer to ECMAScript 6? >> >> 1. The obvious choices: ECMAScript 6 or ES6. >> 2. Suggested by Allen [1]: JavaScript 2015. >> >> The advantage of #2 is that many people don’t know what ECMAScript 6 is. >> However, I’m worried that a book that has “2015” in its title will appear >> old in 2016. And the year scheme completely breaks with current tradition. I >> see two possibilities: >> >> * If there is a concerted effort to establish “JavaScript 2015” then I would >> support that and name my book accordingly. >> * Otherwise, JavaScript 6 is interesting: People who are aware of ECMAScript >> 6 will recognize it, but it will also mean something to people who don’t >> know what ECMAScript is. Is 2015, 2016, … really that much better than 6, 7, >> 8, … ? Would skipped years pose a problem for the former naming scheme? >> >> Axel >> >> [1] https://twitter.com/awbjs/status/558316031039381504 >> >> -- >> Dr. Axel Rauschmayer >> a...@rauschma.de >> rauschma.de >> >> >> >> >> ___ >> es-discuss mailing list >> es-discuss@mozilla.org >> https://mail.mozilla.org/listinfo/es-discuss > > ___ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Property names for public symbols
Agreed, like at the constants on the Math object. --- R. Mark Volkmann Object Computing, Inc. > On Feb 6, 2015, at 12:39 AM, Axel Rauschmayer wrote: > > I know that this is a small nit and that it’s probably too late, but: > Shouldn’t public symbols (`Symbol.iterator` etc.) have all-uppercase property > names? It would indicate that they are constants and it would visually set > them apart from other stuff that is in `Symbol` (`Symbol.for()` etc.). > > -- > Dr. Axel Rauschmayer > a...@rauschma.de > rauschma.de > > > > ___ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Property names for public symbols
I'm curious why one of the public symbols has a name that ends with "Tag"
("toStringTag"), but the others don't (such as "toPrimitive"). Maybe
"toStringTag" should be changed to "toString".
__ __
/ \/ \
\ /ark
Object Computing, Inc.
\ /
\/olkmann
On Sun, Feb 8, 2015 at 4:20 AM, Axel Rauschmayer wrote:
> Got it: public symbols stand for property names and those are typically
> camel-case, starting with a lowercase letter.
>
> On 08 Feb 2015, at 02:09, Brendan Eich wrote:
>
> Axel Rauschmayer wrote:
>
> Can you explain what you mean by “same-named”? You want `Symbol.for()` to
> have the same casing as `Symbol.iterator`?
>
>
> No, I mean we would normally use iterator (and had __iterator__ in
> SpiderMonkey, then '@@iterator' I believe), not ITERATOR. Python's
> dunder-bracketing doesn't cut it, symbols win. But UPPERCASE loses.
>
> /be
>
>
> --
> Dr. Axel Rauschmayer
> a...@rauschma.de
> rauschma.de
>
>
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
iterator next method returning new object
I know there was a discussion about this recently, but I don't recall seeing a reason why it would be problem for a custom iterator to return the same object over and over with different values for the value and done properties. I tried this in some sample code using Traceur and Babel and it works fine. What are the potential problems with doing that? --- R. Mark Volkmann Object Computing, Inc. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
last value from iterator
I thought that when an iterator returns done: true, the value should not be used. However, if a generator function ends by returning a value, done will be true when that value is returned and the value should be used. Given this, how can a consumer know the correct way to handle the value when done is true? Clearly consumers shouldn't have to be aware of whether the iterator is actually a generator and whether it ends by returning a value. --- R. Mark Volkmann Object Computing, Inc. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: last value from iterator
Thanks, that helps. I had been thinking that for-of was a model for how iterators should be consumed. When implementing any kind of iterator (generator or not), it seems important to recognize that if you choose to return a value with done set to true, you are precluding the use of for-of with that iterator (assuming you want all the values). On Sun, Apr 5, 2015 at 11:40 AM, Allen Wirfs-Brock wrote: > > On Apr 5, 2015, at 6:04 AM, Mark Volkmann wrote: > > I thought that when an iterator returns done: true, the value should not > be used. > > > Why do you think that? The definition of the IteratorResult interface in > the the ES6 spec. doesn't say that. > > However, if a generator function ends by returning a value, done will be > true when that value is returned and the value should be used. > > > *Could* be used. Whether a generator or any Iterator provides a > meaningful value when it reach the the 'done' state depends upon its > specific definition. > > Given this, how can a consumer know the correct way to handle the value > when done is true? Clearly consumers shouldn't have to be aware of whether > the iterator is actually a generator and whether it ends by returning a > value. > > > An Iterator does not have to be a generator to provide a 'done' state > value. In general, If you are going to do anything other than basic > iteration, such as is performed by for-of, you need to know about the > specific Iterator you are using. > > Allen > > > -- R. Mark Volkmann Object Computing, Inc. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
generator function requirements
I couldn't find this in spec. Is it required for generator functions to return an object that is both iterable (has Symbol.iterator method) and an iterator (has next method). It seems Babel does this, but I want verify whether that is required. -- R. Mark Volkmann Object Computing, Inc. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: 'stream' values
The entries method of a Map doesn't take a function. It does return an array though. That array contains [key, value] arrays. So you could do this. map.entries().sort(([k1, v1], [k2, v2]) => k1.localeCompare(k2)).forEach(([k, v]) => do-something); --- R. Mark Volkmann Object Computing, Inc. > On May 6, 2015, at 4:27 AM, > wrote: > > Hi, >Can I stream values and operate on them like this ? I have a map and I > would like to stream them. I also want to chain the functions. So, for > example, I may sort the map’s values and pass them on. > > map.entries((e,m) => sort by using a predicate ).foreach(manipulate the map’s > values); > > Thanks, > Mohan > This e-mail and any files transmitted with it are for the sole use of the > intended recipient(s) and may contain confidential and privileged > information. If you are not the intended recipient(s), please reply to the > sender and destroy all copies of the original message. Any unauthorized > review, use, disclosure, dissemination, forwarding, printing or copying of > this email, and/or any action taken in reliance on the contents of this > e-mail is strictly prohibited and may be unlawful. Where permitted by > applicable law, this e-mail and other e-mail communications sent to and from > Cognizant e-mail addresses may be monitored. > ___ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
import ModuleSpecifier
I was under the impression that the following is a valid import statement:
import {something} from './somefile';
I know this used to work in Traceur. However, in the latest version of
Traceur I have to include a file extension like this for it to work:
import {something} from './somefile.js';
I don't see any place in the spec. where it describes whether
ModuleSpecifier should include a file extension. Maybe I just missed it. Is
Traceur correct to require it?
--
R. Mark Volkmann
Object Computing, Inc.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: import ModuleSpecifier
Are you saying that in the future each browser can have its own rule for
module specifier strings?
On Sun, May 31, 2015 at 4:31 PM, Domenic Denicola wrote:
> It is syntactically valid, but there is no specification for what the
> module specifier string should contain. Traceur has one rule, and if you’re
> using Traceur you need to follow Traceur’s rules. I’m sure other
> transpilers have their own chosen rules.
>
>
>
> In a hypothetical future where browsers have a module loader, they will
> have their own rule. Similarly, io.js will have its own.
>
>
>
> *From:* es-discuss [mailto:es-discuss-boun...@mozilla.org] *On Behalf Of *Mark
> Volkmann
> *Sent:* Sunday, May 31, 2015 17:21
> *To:* es-discuss@mozilla.org
> *Subject:* import ModuleSpecifier
>
>
>
> I was under the impression that the following is a valid import statement:
>
>
>
> import {something} from './somefile';
>
>
>
> I know this used to work in Traceur. However, in the latest version of
> Traceur I have to include a file extension like this for it to work:
>
>
>
> import {something} from './somefile.js';
>
>
>
> I don't see any place in the spec. where it describes whether
> ModuleSpecifier should include a file extension. Maybe I just missed it. Is
> Traceur correct to require it?
>
>
>
> --
>
> R. Mark Volkmann
>
> Object Computing, Inc.
>
--
R. Mark Volkmann
Object Computing, Inc.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Re: The Tragedy of the Common Lisp, or, Why Large Languages Explode (was: revive let blocks)
It sounds like you are advocating for a larger standard library in JS. I think many on this thread are focusing on whether more syntax features should be added. On Fri, Jun 19, 2015 at 12:29 PM, Alex Russell wrote: > I do not share Mark's view. Contra his sentiment, I was using the "small" > version of JS for many years and noted that most non-trivial uses required > finding or building a library. That choice of library (which exist to fill > in platform and language deficiencies) leads to a a split in common use > that's just as pernicious as "choosing a subset". > > Writing JS in the large continues to need more help. > > > On Thu, Jun 18, 2015 at 11:27 AM, Andrea Giammarchi < > andrea.giammar...@gmail.com> wrote: > >> I like Mark's post too, and if I might ... >> >> > Features like classes and `let` are very often criticised and often >> languages that did not add these features and are considered 'well >> designed' are given in comparison (Python's lack of block scoping for >> instance). >> >> thing is, ES6 brought in many things that took years to explain in the >> "JS way" and when finally developers started knowing and appreciating >> `prototypal` inheritance and started understanding the `var` behavior, to >> name just few, "we" started promoting ES6 as the universal problem solver >> for every dev so that `let` is the new `var` (most developers still don't >> even know what does it mean) and `const` is the better `let` and `class` >> finally is in the language, something that desugar anyway to prototypal >> inheritance, something developers still need to understand. >> >> So I agree we should really stop going fancy with syntax, probably think >> about sweet.js like approches, and fix all the things that will need to be >> fixed in ES6, improving and finalizing classes bringing in composition like >> it has always been possible before through prototypal inheritance. I really >> do hope traits will be highly prioritized and binary/typed data/shapes too >> 'cause I don't think JS needs many more changes as it is today. >> >> Just my lil'rant and keep up the good work. >> >> Best Regards >> >> >> >> >> >> >> >> >> >> >> On Thu, Jun 18, 2015 at 6:26 PM, Benjamin Gruenbaum > > wrote: >> >>> First of all, brilliant post Mark. >>> >>> > As a community, we need more of a shared sense of panic about the size >>> that ES6 has already grown to. Ideally, that panic should increase, not >>> decrease, with further growth from here as our size approaches the point of >>> no return. >>> >>> As a community, we do - if you look at HackerNews or Reddit or >>> StackOverflow people are constantly hating on JS getting larger. Features >>> like classes and `let` are very often criticised and often languages that >>> did not add these features and are considered 'well designed' are given in >>> comparison (Python's lack of block scoping for instance). >>> >>> This is a mailing list comprised of people who typically have a much >>> better understanding of the language and its corners than most (even >>> professional) developers have (and dare I say, are interested in or care >>> about having). With ES6 the language already got a *lot* bigger and I'd >>> argue that it's now harder to learn the whole. The tradeoffs were >>> worthwhile but it's definitely an issue. >>> >>> It's easy to forget here what traps the average user might fall into, >>> and it's easy to forget what they care about and what confuses them. >>> >>> Fwiw, there are examples of big languages that are well liked, the >>> "canonical" example of a big but very well liked (and well designed imho) >>> language is C#. It has a lot of cruft now (delegates and events, array >>> covariance etc) but it is still a very well liked language in general. >>> >>> >>> >>> ___ >>> es-discuss mailing list >>> es-discuss@mozilla.org >>> https://mail.mozilla.org/listinfo/es-discuss >>> >>> >> >> ___ >> es-discuss mailing list >> es-discuss@mozilla.org >> https://mail.mozilla.org/listinfo/es-discuss >> >> > > ___ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > > -- R. Mark Volkmann Object Computing, Inc. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
treated as a module if ...
Fill in the blank. In ES 2015, a JS source file is treated as a module if _. a. it exports anything b. it imports anything c. both a and b d. something else --- R. Mark Volkmann Object Computing, Inc. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: treated as a module if ...
Thanks for the quick reply! Does this mean that a file that contains imports, but no exports, is not by default evaluated in strict mode? On Sun, Jul 5, 2015 at 8:27 AM, Erik Arvidsson wrote: > d. If a source file is imported it is parsed using the Module production. > > On Sun, Jul 5, 2015, 09:03 Mark Volkmann > wrote: > >> Fill in the blank. >> In ES 2015, a JS source file is treated as a module if _. >> a. it exports anything >> b. it imports anything >> c. both a and b >> d. something else >> >> --- >> R. Mark Volkmann >> Object Computing, Inc. >> ___ >> es-discuss mailing list >> es-discuss@mozilla.org >> https://mail.mozilla.org/listinfo/es-discuss >> > -- R. Mark Volkmann Object Computing, Inc. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
await on synchronous functions
I know the spec for this isn't finalized, but what is the current direction for the behaviour when await is used on a function that is not marked async and doesn't return a Promise? Should it run immediately or wait for the next turn of the event loop? -- R. Mark Volkmann Object Computing, Inc. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: await on synchronous functions
I think this is a valid use case for await working with synchronous
functions.
Suppose I have an array of functions that I want to call in series.
Some are marked async, some return a promise, and some do neither.
I'd like to be able to do something like this:
for (let fn of myFunctions) {
let result = await fn();
// Do something with result.
}
On Fri, Jul 17, 2015 at 1:35 PM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:
> > Think about a large program where you refactor a single async function
> to no longer be async
>
> did that ever happened in the history of logic? I am actually curious to
> understand a single valid case where that would be a solution to any
> problem.
>
> Apologies if I can't see your point but we've been talking about "Promise
> must Promise" so much this answer was absolutely unexpected.
>
> Thanks for any sort of clarification
>
> On Fri, Jul 17, 2015 at 7:27 PM, Tom Van Cutsem
> wrote:
>
>> 2015-07-17 19:41 GMT+02:00 Andrea Giammarchi > >:
>>
>>> If I might, if there's one thing that has never particularly shone in
>>> JS, that is consistency.
>>>
>>> I see only two possibilities here: 1) it throws with non Promises 2) it
>>> "Promisify" anything that's not a Promise as if it was a
>>> `Promise.resolve(1)` ... but since there's too much magic in the second
>>> point, I'd rather stick with the first one.
>>>
>>
>> I would be highly in favor of (2). Think about a large program where you
>> refactor a single async function to no longer be async. Then I see no
>> reason why I should be forced to refactor all of its callers to remove the
>> await keyword. Going from sync to async requires refactoring because you're
>> introducing new potential interleaving hazards, but any code that is
>> already prepared to work with async functions (or promises in general)
>> should work equally fine on immediately resolved promises.
>>
>> regards,
>> Tom
>>
>>
>>
>>>
>>> Just my quick thoughts
>>>
>>> Best Regards
>>>
>>> On Fri, Jul 17, 2015 at 6:33 PM, Kevin Smith
>>> wrote:
>>>
>>>> I know the spec for this isn't finalized, but what is the current
>>>>> direction for the behaviour when await is used on a function that is not
>>>>> marked async and doesn't return a Promise? Should it run immediately or
>>>>> wait for the next turn of the event loop?
>>>>>
>>>>
>>>> More generally, the question is: what should await do for non-promises?
>>>>
>>>> await 1;
>>>>
>>>> Should it force a job to be queued?
>>>>
>>>> ___
>>>> es-discuss mailing list
>>>> es-discuss@mozilla.org
>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>
>>>>
>>>
>>> ___
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
--
R. Mark Volkmann
Object Computing, Inc.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: await on synchronous functions
;>>>>> More generally, the question is: what should await do for >>>>>> non-promises? >>>>>> >>>>>> await 1; >>>>>> >>>>>> Should it force a job to be queued? >>>>>> >>>>>> ___ >>>>>> es-discuss mailing list >>>>>> es-discuss@mozilla.org >>>>>> https://mail.mozilla.org/listinfo/es-discuss >>>>>> >>>>>> >>>>> >>>>> ___ >>>>> es-discuss mailing list >>>>> es-discuss@mozilla.org >>>>> https://mail.mozilla.org/listinfo/es-discuss >>>>> >>>>> >>>> >>> ___ >>> es-discuss mailing list >>> es-discuss@mozilla.org >>> https://mail.mozilla.org/listinfo/es-discuss >>> >> >> ___ >> es-discuss mailing list >> es-discuss@mozilla.org >> https://mail.mozilla.org/listinfo/es-discuss >> >> > > ___ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > > -- R. Mark Volkmann Object Computing, Inc. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: await on synchronous functions
async function to no longer be async. Then I see no >>>>> reason why I should be forced to refactor all of its callers to remove the >>>>> await keyword. Going from sync to async requires refactoring because >>>>> you're >>>>> introducing new potential interleaving hazards, but any code that is >>>>> already prepared to work with async functions (or promises in general) >>>>> should work equally fine on immediately resolved promises. >>>>> >>>>> regards, >>>>> Tom >>>>> >>>>> >>>>> >>>>>> >>>>>> Just my quick thoughts >>>>>> >>>>>> Best Regards >>>>>> >>>>>> On Fri, Jul 17, 2015 at 6:33 PM, Kevin Smith >>>>>> wrote: >>>>>> >>>>>>> I know the spec for this isn't finalized, but what is the current >>>>>>>> direction for the behaviour when await is used on a function that is >>>>>>>> not >>>>>>>> marked async and doesn't return a Promise? Should it run immediately or >>>>>>>> wait for the next turn of the event loop? >>>>>>>> >>>>>>> >>>>>>> More generally, the question is: what should await do for >>>>>>> non-promises? >>>>>>> >>>>>>> await 1; >>>>>>> >>>>>>> Should it force a job to be queued? >>>>>>> >>>>>>> ___ >>>>>>> es-discuss mailing list >>>>>>> es-discuss@mozilla.org >>>>>>> https://mail.mozilla.org/listinfo/es-discuss >>>>>>> >>>>>>> >>>>>> >>>>>> ___ >>>>>> es-discuss mailing list >>>>>> es-discuss@mozilla.org >>>>>> https://mail.mozilla.org/listinfo/es-discuss >>>>>> >>>>>> >>>>> >>>> ___ >>>> es-discuss mailing list >>>> es-discuss@mozilla.org >>>> https://mail.mozilla.org/listinfo/es-discuss >>>> >>> >>> ___ >>> es-discuss mailing list >>> es-discuss@mozilla.org >>> https://mail.mozilla.org/listinfo/es-discuss >>> >>> >> > ___ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > > -- R. Mark Volkmann Object Computing, Inc. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
for-of loop
I understand Arrays in ES 2015 are both iterable (have Symbol.iterator method) and iterators (have next method). Suppose I create a custom object foo that is iterable, but not an iterator because the Symbol.iterator method returns a different object bar. According to the spec, should I be able to use either foo or bar after "of" in a for-of loop? --- R. Mark Volkmann Object Computing, Inc. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: for-of loop
Ah, yes. I was getting that confused with what is returned by the Array methods entries, keys, and values which is an object that is both iterable and an iterator. Thanks for clarifying that the value after "of" in a for-of loop must be an iterable, not an iterator. On Sat, Aug 22, 2015 at 10:42 AM, Alexander Jones wrote: > Arrays are not iterators - they have no `next` method. '`for-of` works on > iterables. > > > On Saturday, August 22, 2015, Mark Volkmann > wrote: > >> I understand Arrays in ES 2015 are both iterable (have Symbol.iterator >> method) and iterators (have next method). Suppose I create a custom object >> foo that is iterable, but not an iterator because the Symbol.iterator >> method returns a different object bar. According to the spec, should I be >> able to use either foo or bar after "of" in a for-of loop? >> > -- R. Mark Volkmann Object Computing, Inc. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
let and file scope
Does a top-level let in a file (not inside any function) create a global variable just like var or does it create a variable that is scoped to the source file? --- R. Mark Volkmann Object Computing, Inc. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Array.of
What is an example of a use case where one would choose to use Array.of instead of the literal array syntax? -- R. Mark Volkmann Object Computing, Inc. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
typed arrays
Are typed arrays considered to be part of ES6? I see they are described in the ES6 working draft, but when I find lists of ES6 features on the web, I never see those included. I see they are also described in a separate specification here: http://www.khronos.org/registry/typedarray/specs/latest/ . -- R. Mark Volkmann Object Computing, Inc. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Template strings and templates
It seems to me that the main benefit is that it takes care of parsing out the template parts around the expressions for you. Otherwise you might write a regular expression to do that. --- R. Mark Volkmann Object Computing, Inc. > On Mar 6, 2014, at 5:29 PM, Caitlin Potter wrote: > > What exactly is being accomplished with tagged templates? I mean, what is the > use case? It seems to make certain specific function calls look very > different from a typical function call, the arguments passed in are not very > clearly explained in the draft or wiki, and I have difficulty imagining > anyone actually using these for anything. I would love to hear a solid case > for these (I've been looking for the past few nights, but nothing has shown > up). Template literals are great, but the `tagging` thing seems fishy for the > vast majority of applications. > > I'm not saying they shouldn't be included in harmony, i'm just very > interested in finding out what practical task they are meant to accomplish > ___ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
module exports
I'm trying to understand the options for exporting things from a module.
Here's how I think it works, mostly based on what I see in Traceur.
Does any of this look wrong?
To export a value,
export var someName = someValue;
To export a function,
export function someName(args) { ... };
To export multiple things defined elsewhere in this file,
export {name1, name2, ...};
Here's the part that confuses me most. It seems that importers have three
options.
1) import specific things from a given module
2) import everything that was exported from a given module
3) import a subset of what a given module exports that it identified as the
"default" (presumably the most commonly used things)
To define the default subset of things to export from a module,
export default = some-value or some-function;
where some-value could be an object holding a collection of things to
export.
--
R. Mark Volkmann
Object Computing, Inc.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: module exports
I have used Node.js extensively. In that environment, as I'm sure you know,
a module exports one thing. It can be an object with lots of properties on
it, a single function, or a single value. I suppose you could say that all
Node has is a "default" export which is the one thing the module exports.
I'm trying to understand how that compares to ES6 modules. I see how in ES6
I can import specific things from a module or I can import everything a
module exports. Am I correct that a "default" export can be somewhere in
the middle ... a subset of everything that is exported?
On Fri, Mar 14, 2014 at 8:22 AM, Domenic Denicola <
dome...@domenicdenicola.com> wrote:
> Have you ever used JavaScript module systems before? If so, the idea of a
> default export should be somewhat familiar...
>
> > On Mar 14, 2014, at 6:31, "Mark Volkmann"
> wrote:
> >
> > I'm trying to understand the options for exporting things from a module.
> > Here's how I think it works, mostly based on what I see in Traceur.
> > Does any of this look wrong?
> >
> > To export a value,
> > export var someName = someValue;
> >
> > To export a function,
> > export function someName(args) { ... };
> >
> > To export multiple things defined elsewhere in this file,
> > export {name1, name2, ...};
> >
> > Here's the part that confuses me most. It seems that importers have
> three options.
> > 1) import specific things from a given module
> > 2) import everything that was exported from a given module
> > 3) import a subset of what a given module exports that it identified as
> the "default" (presumably the most commonly used things)
> >
> > To define the default subset of things to export from a module,
> > export default = some-value or some-function;
> > where some-value could be an object holding a collection of things to
> export.
> >
> > --
> > R. Mark Volkmann
> > Object Computing, Inc.
> > ___
> > es-discuss mailing list
> > es-discuss@mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
>
--
R. Mark Volkmann
Object Computing, Inc.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: module exports
On Fri, Mar 14, 2014 at 8:54 AM, Kevin Smith wrote:
>
>> I'm trying to understand how that compares to ES6 modules. I see how in
>> ES6 I can import specific things from a module or I can import everything a
>> module exports.
>>
>
> You can't really import all exported bindings. You can import the module
> instance object itself:
>
> module M from "wherever";
>
> which will give you access to all of the exports.
>
That's what I meant by importing all the exports.
I'd prefer it if the syntax for that was
import M from "wherever";
That way I could think of import is doing something like destructuring
where the other syntax below is just getting some of the exports.
import {foo, bar} from "wherever"';
>
>
>> Am I correct that a "default" export can be somewhere in the middle ... a
>> subset of everything that is exported?
>>
>
> Not really. The default export is literally just an export named
> "default". There is sugar on the import side, where you can leave off the
> braces:
>
> import foo from "somewhere";
>
> is equivalent to:
>
> import { default as foo } from "somewhere";
>
> The specialized default export syntax is just plain confusing and should
> be jettisoned, in my opinion. It would be less confusing for users to
> simply write:
>
> export { foo as default };
>
> I fail to see why sugar over this form is necessary.
>
I completely agree. Plus if this is taken away then the "import" keyword
can be used to get the whole module as in my example above. At that point
maybe there is no need for the "module" keyword.
--
R. Mark Volkmann
Object Computing, Inc.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: module exports
I understand it's hard to make changes after a certain point. It's too bad
though that developers will have to remember that the way to import a few
things from a module is:
import {foo, bar} from 'somewhere';
but the way to import the whole module is:
module SomeModule from 'somewhere';
instead of
import SomeModule from 'somewhere';
It just seems so clean to say that if you want to import something, you
always use the "import" keyword.
On Fri, Mar 14, 2014 at 9:12 AM, Kevin Smith wrote:
> export { foo as default };
>>>
>>> I fail to see why sugar over this form is necessary.
>>>
>>
>> I completely agree. Plus if this is taken away then the "import" keyword
>> can be used to get the whole module as in my example above. At that point
>> maybe there is no need for the "module" keyword.
>>
>
> Maybe, but at this point that would be too big of a change to swallow. I
> think if we can just focus on eliminating this one pointless and confusing
> aspect (the export default [expr] form), we'll be good to go.
>
>
>
--
R. Mark Volkmann
Object Computing, Inc.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: module exports
Is the common use case for "export default" when you want to give users of
the module an easy way to obtain a single function?
So instead of users doing this:
import {someFn} from 'wherever';
they can do this:
import someFn from 'wherever';
On Fri, Mar 14, 2014 at 9:40 AM, Rick Waldron wrote:
>
>
>
> On Fri, Mar 14, 2014 at 10:07 AM, Mark Volkmann > wrote:
>
>> On Fri, Mar 14, 2014 at 8:54 AM, Kevin Smith wrote:
>>
>>>
>>>> I'm trying to understand how that compares to ES6 modules. I see how in
>>>> ES6 I can import specific things from a module or I can import everything a
>>>> module exports.
>>>>
>>>
>>> You can't really import all exported bindings. You can import the
>>> module instance object itself:
>>>
>>> module M from "wherever";
>>>
>>> which will give you access to all of the exports.
>>>
>>
>> That's what I meant by importing all the exports.
>> I'd prefer it if the syntax for that was
>>
>> import M from "wherever";
>>
>
> As Kevin said, this already means "import the default export from
> 'wherever'"
>
>
>>
>> That way I could think of import is doing something like destructuring
>> where the other syntax below is just getting some of the exports.
>>
>> import {foo, bar} from "wherever"';
>>
>>
>>>
>>>
>>>> Am I correct that a "default" export can be somewhere in the middle ...
>>>> a subset of everything that is exported?
>>>>
>>>
>>> Not really. The default export is literally just an export named
>>> "default". There is sugar on the import side, where you can leave off the
>>> braces:
>>>
>>> import foo from "somewhere";
>>>
>>> is equivalent to:
>>>
>>> import { default as foo } from "somewhere";
>>>
>>> The specialized default export syntax is just plain confusing and should
>>> be jettisoned, in my opinion. It would be less confusing for users to
>>> simply write:
>>>
>>> export { foo as default };
>>>
>>> I fail to see why sugar over this form is necessary.
>>>
>>
> Because it doesn't allow for the Assignment Expression form (specifically,
> function expressions) that developers expect to be able to write:
>
> export default function() {}
>
> Rick
>
--
R. Mark Volkmann
Object Computing, Inc.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
ES6 iteration over object values
Does ES6 add any new ways to iterate over the values in an object?
I've done a lot of searching, but haven't seen anything.
I'm wondering if there is something more elegant than this:
Object.keys(myObj).forEach(function (key) {
let obj = myObj[key];
// do something with obj
});
--
R. Mark Volkmann
Object Computing, Inc.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
article on ES6 and Traceur
Here's an article I wrote recently that may be of interest. It covers automating the use of Traceur to generate ES5 code. http://sett.ociweb.com/sett/settApr2014.html -- R. Mark Volkmann Object Computing, Inc. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
await and promise
I looked at the "async" keyword examples in Traceur for the first time
today. Cool stuff!
IIUC, when a function is annotated with the async keyword, it can use
"await" and the "done" function is magically defined.
An interesting corollary to that idea would be to introduce a "promise"
keyword that can be used to annotate a function. It would magically define
the functions "resolve" and "reject". It would allow a function like this:
function foo() {
return new Promise((resolve, reject) => {
// some code that eventually calls resolve or reject
});
}
to be written like this:
promise function foo() {
// some code that eventually calls resolve or reject
}
Is this a crazy idea? Perhaps if this was available, it would be very rare
to actually write "new Promise(" in code.
--
R. Mark Volkmann
Object Computing, Inc.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: await and promise
I have seen that in Mocha tests, but this code looked different to me.
I'm looking at
https://github.com/google/traceur-compiler/blob/master/test/feature/AsyncFunctions/AlphaRenaming.js
.
I thought to use done in a Mocha test you have to have a parameter named
"done" in the test function.
I suppose I was wrong about that.
On Sun, Mar 30, 2014 at 8:59 AM, Erik Arvidsson wrote:
> The done function is injected by the Traceur test runner for async tests.
> It is standard mocha stuff.
>
>
> On Sunday, March 30, 2014 9:06:23 AM, Mark Volkmann <
> r.mark.volkm...@gmail.com> wrote:
>
>> I looked at the "async" keyword examples in Traceur for the first time
>> today. Cool stuff!
>>
>> IIUC, when a function is annotated with the async keyword, it can use
>> "await" and the "done" function is magically defined.
>>
>> An interesting corollary to that idea would be to introduce a "promise"
>> keyword that can be used to annotate a function. It would magically define
>> the functions "resolve" and "reject". It would allow a function like this:
>>
>> function foo() {
>> return new Promise((resolve, reject) => {
>> // some code that eventually calls resolve or reject
>> });
>> }
>>
>> to be written like this:
>>
>> promise function foo() {
>> // some code that eventually calls resolve or reject
>> }
>>
>> Is this a crazy idea? Perhaps if this was available, it would be very
>> rare to actually write "new Promise(" in code.
>>
>> --
>> R. Mark Volkmann
>> Object Computing, Inc.
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
--
R. Mark Volkmann
Object Computing, Inc.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Rationale for dropping ModuleImport syntax?
I would like to see a reigning in of uses of curly braces. We already have
at least these:
1) code blocks
2) literal objects
3) destructuring
I don't like that the module syntax adds yet another. I'd like to think of
the curly braces in the module syntax as being like destructuring. That way
the mental model could be that whenever you see curly braces on what is
conceptually the left-hand side of an expression, you can at least think of
it as being like destructuring.
So the following would mean I want all the exports as a single object:
import fs from "fs";
and the following would mean I only want some of the exports from a module:
import {mkdir, write} from "fs";
Maybe the following could be used to get the "default" export from a module:
import default fsd from "fs";
On Mon, Jun 9, 2014 at 9:51 AM, Axel Rauschmayer wrote:
> I’m assuming that people will default-export objects (for
> Underscore.js-like libraries). I’d call those pseudo-modules, because one
> would be partially working around the module system (no load-time errors!).
>
> Maybe we’ll import modules like this [^1], but that feels syntactically
> inconsistent to me and you don’t get load-time errors, either:
>
> ```js
> import "Underscore";
> const _ = System.get("Underscore");
> ```
>
> [^1]: https://gist.github.com/domenic/2230a7195fa0de31a227
>
>
>
> On Jun 9, 2014, at 16:28 , John Barton wrote:
>
>
>
>
> On Mon, Jun 9, 2014 at 6:54 AM, Axel Rauschmayer wrote:
>
>> On the other hand, we’ll have many pseudo-modules, which is also a
>> barrier against making progress later on.
>>
>
> Sorry, I don't understand what a pseudo-module is. Are you saying that the
> core import/export system is not correct and that we should have a system
> based exclusively on 'module'?
>
> jjb
>
>
> --
> Dr. Axel Rauschmayer
> a...@rauschma.de
> rauschma.de
>
>
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
--
R. Mark Volkmann
Object Computing, Inc.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 modules (sorry...)
Yes! Don't make it look like destructuring and then say it's nothing like that. At this point I'd be happy to be able to only get back one thing from an import (no destructure-like syntax) that could be any kind of value, including an object with lots of methods on it like we are used to in Node.js. If I want the properties from such an object to be in variables, I can destructure that object in one more line of code. On Mon, Jun 16, 2014 at 12:39 PM, Matthew Robb wrote: > I wonder if it would help reduce confusion if the syntax wasn't so similar > to destructuring: > > import ( foo, bar ) from "library"; > > or > >> import < foo, bar > from "library"; > > > > - Matthew Robb > > > On Mon, Jun 16, 2014 at 10:24 AM, Domenic Denicola < > dome...@domenicdenicola.com> wrote: > >> I'm not talking about MIO properties. I'm talking about the bindings >> created by import declarations. >> -- >> From: Sam Tobin-Hochstadt >> Sent: 2014-06-16 13:21 >> To: Domenic Denicola >> Cc: Calvin Metcalf ; es-discuss Steen >> ; C. Scott Ananian >> Subject: RE: ES6 modules (sorry...) >> >> >> On Jun 16, 2014 1:06 PM, "Domenic Denicola" >> wrote: >> > >> > From: es-discuss on behalf of C. >> Scott Ananian >> > >> > > Using destructuring syntax for imports would be a *good thing*. It >> builds on our existing understanding of JS constructs, instead of adding >> more gratuitously different things to learn. >> > >> > This would be a very *bad thing*, as long as the current model---where >> exports are something wildly different from properties of an object, but >> instead are cross-file `with`-esque read-only-but-mutable bindings---was >> maintained. It's extremely important that these bindings look and are >> manipulated as differently as possible from normal declarations and >> destructuring of object properties. >> >> In fact, module instance object properties behave nothing like with, and >> are just like an object with a getter but no setter. Just as with any other >> getter, they don't always return the same answer, but that doesn't make >> them anything like with. >> >> Perhaps you think JS should get rid of setters and getters, if you think >> they're like with, but you should just say that if so. >> >> Sam >> >> ___ >> es-discuss mailing list >> es-discuss@mozilla.org >> https://mail.mozilla.org/listinfo/es-discuss >> >> > > ___ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > > -- R. Mark Volkmann Object Computing, Inc. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ModuleImport
What is the behavior if a module doesn't define a default export and the syntax
for importing the default export is used?
What is the behavior if a module only defines a default export and the syntax
for importing named imports is used?
---
R. Mark Volkmann
Object Computing, Inc.
> On Jun 19, 2014, at 3:15 AM, David Herman wrote:
>
> 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 ModuleImport and default import is
> vague.**
>
> We've consistently seen confusion between the semantics of ModuleImport and
> default export. While certainly some of the confusion might be chalked up to
> misinformation and lack of documentation, we've seen people be confused by
> this even when correctly explained the semantics. The problem with the syntax
> is that the only visual distinction is the initial keyword (`module` vs
> `import`), and it's not clear from that keyword which concept you're talking
> about. (Once you've internalized the structure of module instance objects,
> you get a hint from the `module` keyword, but that doesn't help people who
> are just learning the system, particularly if they're already familiar with
> other JS module systems.)
>
> Against removal:
>
> * **Without ModuleImport, authors of multi-export modules would be pressured
> to circumvent the named exports functionality.**
>
> Without ModuleImport, clients of multi-export modules have two options.
> Either they use named import:
> ```js
> import { readFile, writeFile } from "fs";
> ```
> or if they want to explicitly namespace those functions, they have to use the
> dynamic API:
> ```js
> import "fs"; // state the dependency
> var fs = this.get("fs");
> ```
> That's inconvenient, confusing, and makes you feel like you're stepping
> outside the normal usage patterns intended for the system. Since this is a
> choice forced on the clients of a module, the module author will feel
> pressure to circumvent the named export feature altogether and instead export
> a default object with all the properties. This is bad -- it creates pressure
> for people to abandon part of the module system.
>
> ## Conclusion
>
> Here's the conclusion I've come to based on all of the above.
>
> * **We need a form like ModuleImport.**
>
> As many have said, clients of named-export modules need the freedom to choose
> whether to explicitly namespace those imports, and they need a syntax that
> doesn't feel like they've stepped outside the normal system.
>
> * **The current syntax of ModuleImport is wrong.**
>
> The confusion reported in developer feedback is real, and it's important.
>
> * **The syntax should still favor default import.**
>
> ES6 favors the single/default export style, and gives the sweetest syntax to
> importing the default. Importing named exports can and even should be
> slightly less concise.
>
> * **A better ModuleImport syntax is possible, and we should settle it soon.**
>
> I'll propose a better ModuleImport syntax below. Syntax being syntax,
> everyone will of course unsheathe their bikeshed paintbrush. That's OK. The
> champions will keep it from going on unbounded and help settle the debate,
> and we'll make sure to capture the conclusion in the next TC39 meeting.
>
> I do acknowledge the concerns about reopening topics for debate and delay.
> But given the usability feedback, I think this case is worth fixing. We
> should resolve it for ES6, perhaps in part because it's less editorial work
> to change the ModuleImport production than to defer it, but more because I
> don't want to delay the resolution so that implementations can ship the
> better syntax. But keep in mind it doesn't matter what spec it lands in as
> long as implementations are shipping it. We're still in the early days of
> transpiler implementations, and there are no native implementations of
> modules yet. So there's time, as long as we don't let the bikeshed go on
> forever. So let's get to it!
>
> ## Proposal
>
> OK, so we're talking about a better syntax for importing a module and binding
> its named exports to a variable (as distinct from importing a module and
> binding its default export to a variable). Here's my proposal:
> ```js
> import * as fs from "fs"; // importing the named exports as an
Re: ModuleImport
On Thu, Jun 26, 2014 at 9:50 AM, Russell Leggett
wrote:
>
>>> To me, though, that goes back to the destructuring/not destructuring
> aspect. Maybe this has floated by during the bikeshedding, but why not
> something like:
>
> //import a single named export
> import foo from "bar";
>
> //import multiple named exports
> import foo, baz from "bar";
>
> //alias an imported named export
> import foo as fooAlias from "bar";
>
> //import the module
> import "bar" as bar;
>
> So basically, just get rid of the {} for importing named exports, and move
> the whole module import after the as.
>
Yes! I would SO much happier with this if the curly braces were removed.
--
R. Mark Volkmann
Object Computing, Inc.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
ES6 talk slides
Here's a link to my slides from a recent talk I gave on ES6. I thought some on this list my find it interesting and others might send me corrections. ;-) http://sett.ociweb.com/sett/settJul2014.html -- R. Mark Volkmann Object Computing, Inc. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 talk slides
Are you sure? I just tried it and it worked for me. On Wed, Jul 9, 2014 at 1:23 PM, Maxime Warnier wrote: > Your link seems to be broken ;) > > > 2014-07-09 17:41 GMT+02:00 Mark Volkmann : > >> Here's a link to my slides from a recent talk I gave on ES6. >> I thought some on this list my find it interesting >> and others might send me corrections. ;-) >> >> http://sett.ociweb.com/sett/settJul2014.html >> >> -- >> R. Mark Volkmann >> Object Computing, Inc. >> >> ___ >> es-discuss mailing list >> es-discuss@mozilla.org >> https://mail.mozilla.org/listinfo/es-discuss >> >> > > > -- > Maxime WARNIER > -- R. Mark Volkmann Object Computing, Inc. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Single import from modules without default export
+1 to Kevin's suggestions. --- R. Mark Volkmann Object Computing, Inc. On Aug 6, 2014, at 7:10 AM, Kevin Smith wrote: >> >> Completely agree, the default should be removed. This is simply a proposal >> of how we can still have a simple import statement (`import $ from >> "jQuery";`) without needing `default`. > > You know, I hate even suggesting any syntax changes at this point, but if we > ditched the whole "default" thing, we could probably also get rid of the > curlies: > > import readFile, writeFile from "node:fs"; > > And then "* as" would fit in naturally: > > import * as FS, readFile from "node:fs"; > > I think this might result in on overall better user experience. I'll > experiment with this from a parsing standpoint. > > What would you think about that? > > ___ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: javascript vision thing
For me the biggest thing JSON lacks is the ability to add comments. --- R. Mark Volkmann Object Computing, Inc. > On Jul 25, 2018, at 4:26 AM, Isiah Meadows wrote: > > IMHO, I'd like to see four things: > > - Native JSON multi-object support > - Binary data support that doesn't require delimiters > - Native JSON property streaming support > - Spec-level binary JSON support > > Apart from that, I don't really see anything JSON lacks. > > - > > Isiah Meadows > m...@isiahmeadows.com > www.isiahmeadows.com > >> On Tue, Jul 24, 2018 at 12:43 PM, Carsten Bormann wrote: >> >>> On Jul 24, 2018, at 18:29, Anders Rundgren >>> wrote: >>> >>>> On 2018-07-24 17:09, Carsten Bormann wrote: >>>>> On Jul 24, 2018, at 16:31, Anders Rundgren >>>>> wrote: >>>>> >>>>> JSON isn’t really a topic for tc39 only but since the IETF consider JSON >>>>> "done", an open question is where possible future developments should >>>>> take place, >>>> No, that is not the question. >>>>> including dealing with new data types like BigInt. >>>> That, indeed, is a question for JavaScript. It has nothing to do with >>>> “developing” JSON; JSON can already represent BigInt just fine. >>> >>> Serializing BigInt as JSON Number is the solution then? >> >> For applications that make good use of BigInt, I would say so. >> So you wouldn’t use JSON.parse, but a new interface that preserves integers >> beyond 2**53 as BigInt (or possibly even all integers; I don’t want to >> design this on a napkin) >> >>> There are a few argument against that: >>> >>> - This would typically require low-level parsers to always rely on a >>> BigNumber type. Oracle's JSON-B does exactly that. Currently there is no >>> BigNumber type in JS or .NET. >> >> There is no need for the above interface to handle floating point numbers >> (NR2/NR3). >> >>> - There is quite a bunch of IETF standards defining JSON structures. As far >>> as I know none of them exploit JSON outside of its original, JS-induced >>> limitations. >> >> Maybe the IETF was smart enough to stay in the confines of I-JSON… >> >> But really, JSON never had that particular limitation. A JSON-based >> ecosystem that wants to enable the use of JavaScript JSON.parse does, as >> Twitter found out when they were sending their perfectly valid JSON to >> JavaScript applications. >> >>> - Although BigInt is a very welcome addition to JS, usages are few and >>> typically confined to specific things like crypto or money. Creating >>> backward incompatibility for that is IMO counterproductive. >> >> Right, so maybe the motivation for touching JSON really isn’t that massive. >> >>> - Serializing BigInts as a string does not break anything. >> >> After JSON.parse, they are text strings then, not BigInts. >> Generally, there is the expectation that, for an interesting set of x, >> JSON.parse(JSON.stringify(x)) == x >> Hence the exception when you pass BigInt to JSON.stringify today. >> >>>>> Personally I think the JSON WG should be rebooted but apparently I’m >>>>> rather alone with that idea. >>>> Indeed. >>> >>> That might be the case but it doesn’t solve the problem. >> >> It also doesn’t create the problem of damaging JSON by instability. >> >>>> Frankly, JSON, together with the JavaScript-induced limitations in its >>>> ecosystem as documented in RFC 7493, is not a very brilliant data >>>> interchange format. >>> >>> It seems to work well in spite of not being brilliant. >> >> Right. As do bicycles. Until you need to transport a sofa or cross the >> Atlantic. >> JSON is the right tool for a large number of jobs. >> >>> Yes, CBOR is great https://tools.ietf.org/html/rfc7049 :-) >> >> Can’t disagree here :-) >> >> Grüße, Carsten >> >> ___ >> es-discuss mailing list >> es-discuss@mozilla.org >> https://mail.mozilla.org/listinfo/es-discuss > ___ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
