Not having JSON support for BigInt is a big problem. But the fact exists
that JSON does not cover everything. It doesn't cover Dates, Maps, Sets,
Symbols...
Until/unless the successor to JSON (whatever it may be) is created and
adopted, a process that will take years, let's take a pragmatic
I've just finished updating my proposal with an [Existing proposals](
https://github.com/rdking/proposal-object-members/blob/master/README.md#existing-proposals)
section that lists the major differences.
On Thu, Jul 26, 2018 at 9:00 AM Ranando King wrote:
> Thank you for the advice. Those will
On Thu, Jul 26, 2018 at 5:23 PM, Anders Rundgren
wrote:
> On 2018-07-26 17:24, Ranando King wrote:
>>
>> JSON = JavaScript Object Notation
>
> This obviously broke down when tc39 introduced BigInt leaving the JSON/JS
> community in limbo.
Not supporting all of JavaScript's features is nothing
On 2018-07-26 17:24, Ranando King wrote:
JSON = JavaScript Object Notation
This obviously broke down when tc39 introduced BigInt leaving the JSON/JS
community in limbo.
Anders
___
es-discuss mailing list
es-discuss@mozilla.org
That's a ridiculous claim, considering JSON has never supported functions,
or `undefined`, or RegExps, or Dates.
ES6 also introduced `Symbol`, `Map`, `Set`, etc all of which have no JSON
representation.
There's no "limbo" - JSON is, and will forever be, a subset of JS. Many new
things will be
Thank you, TJ. Those are some other interesting options. But undesirable,
like you say, least of which because they all require repetition like my
snippet in my original post. At least the array of properties avoids the
repetition. I agree it's not ideal because of the extra quote marks, but my
Thanx T.J.
With your suggestion there are now not less than FIVE proposals on the table
for dealing with BigInt JSON serialization:
*RFC8259: 123456789123456789123456789
ES6 enhanced: 123456789123456789123456789n
Typed: "/BigInt(123456789123456789123456789)/"
*Adaptive:
On Wed, Jul 25, 2018 at 10:45 PM, Mikkel Davis
wrote:
> I've seen proposals for syntax additions that give functionality
> similar to lodash's "pick" utility. But I think it may be more
> appropriate to add it as an Object utility in the same vein of
What I don't like about it being a utility
Let me see if I can clarify things a bit:
You're not misunderstanding. I've spent a fair amount of time in discussion
on github in those very same issues. For various reasons, probably mostly
due to the time investment the proponents of those proposals have given, it
seems to be the prevailing
FWIW I have never heard of this terminology before either but in practice
have used the pattern myself.
On Thu, Jul 26, 2018 at 12:15 AM, Bob Myers wrote:
> > It allows you to reveal things, selectively, just as the revealing
> module pattern does. \
>
> The revealing module pattern is so named
Even if we don't get do expressions, the proposal I've recently submitted
includes this ability as a side effect.
https://github.com/rdking/proposal-object-members/blob/master/README.md
On Wed, Jul 25, 2018 at 6:42 AM T.J. Crowder <
tj.crow...@farsightsoftware.com> wrote:
> On Wed, Jul 25, 2018
@Mikkel,
My impression is that one can summarize the attitude of people on this
mailing list and those involved in the language design process toward
property picking as somewhere between "I don't care enough to worry about
it" and "it doesn't belong in the language". To put it a different way,
On Thu, Jul 26, 2018 at 7:28 AM, Ranando King wrote:
> Let me see if I can clarify things a bit:
Thanks! That does indeed clear things up a lot.
I'd find it helpful (just speaking for myself here) if the proposal opened
with a series of specific differences with the two existing proposals and
I started wrapping the idea here https://github.com/caub/proposal-range
On Wed, Jul 18, 2018 at 6:48 PM Cyril Auburtin
wrote:
> I really like this possible new syntax for ranges:
>
> ```js
> [2:9] // [2,3,4,5,6,7,8,9]
> [1, 2, 4:7, 9] // [1, 2, 4, 5, 6, 7, 9]
> [1:6:2] // [1, 3, 5]
> ```
>
>
Thank you for the advice. Those will be the next updates I make to the
proposal.
On Thu, Jul 26, 2018 at 3:32 AM T.J. Crowder <
tj.crow...@farsightsoftware.com> wrote:
> On Thu, Jul 26, 2018 at 7:28 AM, Ranando King wrote:
> > Let me see if I can clarify things a bit:
>
> Thanks! That does
Another lurker, and I agree with both points:
* I think JS *is* useful for way more than just the Web. It might not be
my favorite language of all times, but sure is near the top and my language
of choice for several non-web projects, specially bash scripts (I have
simple bash utility in JS that
Here's the funny part:
JSON = JavaScript Object Notation
If the OP wants to see improvements in JSON, why not just submit a proposal
to alter what ES can do with JSON? If it makes it to stage 4, there's a
pretty good chance that the standard for JSON will also change as a result.
Sitting around
I'm a half lurker, as I've participated and thrown out ideas.
I've embedded javascript as a scripting languages outside the web, in
both personal and non-personal projects. I've used Javascript to write
games or experiments just to amuse myself, and this is coming from a
person who still
18 matches
Mail list logo
