Re: Pointers

On Mon, Mar 19, 2018 at 6:17 PM, J Decker wrote: > > > On Mon, Mar 19, 2018 at 6:01 PM, Isiah Meadows > wrote: > >> C# isn't the only OO language to have references. PHP has them too, >> although the awkwardness isn't the references themselves as much

Re: Pointers

On Mon, Mar 19, 2018 at 6:01 PM, Isiah Meadows wrote: > C# isn't the only OO language to have references. PHP has them too, > although the awkwardness isn't the references themselves as much as > how the language integrates with them. OCaml also has reified > references

Re: Pointers

C# isn't the only OO language to have references. PHP has them too, although the awkwardness isn't the references themselves as much as how the language integrates with them. OCaml also has reified references as separate from their mutable record properties. Note that C#'s "out" parameters aren't

Re: Pointers

Ahh parameters by reference yes have wished for that... ref is C#-ism to me... which also maybe 'out' which really isn't different in JS in C# it enforces that the value is set in the function receiving an out 'must give value to parameter'. On Mon, Mar 19, 2018 at 5:28 PM, Isiah Meadows

Re: Pointers

This is basically what I was proposing, ironically enough. There's a few small differences, but the only one that substantially varied from mine I filed an issue in your repo against. (I almost went for `value`.) BTW, yours looks a *lot* like OCaml's `ref 'a` type, which is just sugar for

RE: Pointers

Ron: Very interesting, in particular, the function arguments by reference aspect. Thanks. Claude -Original Message- From: Ron Buckton Sent: Monday, March 19, 2018 7:58 PM To: Isiah Meadows ; Michael J. Ryan Cc:

RE: Pointers

> -Original Message- > From: Pier Bover > Sent: Monday, March 19, 2018 5:06 PM > To: Isiah Meadows > Cc: Ron Buckton ; es-discuss disc...@mozilla.org> > Subject: Re: Pointers > > So the proposal is basically

Re: Pointers

Yes that is basically what I want anyway Sebastian Malton

Re: Pointers

So the proposal is basically having references to primitives like strings, bools, etc? On Mon, Mar 19, 2018, 6:59 PM Isiah Meadows wrote: > Yeah, I meant "references", not "pointers"... My bad. > - > > Isiah Meadows > m...@isiahmeadows.com > > Looking for web

Re: Pointers

Yeah, I meant "references", not "pointers"... My bad. - Isiah Meadows m...@isiahmeadows.com Looking for web consulting? Or a new website? Send me an email and we can get started. www.isiahmeadows.com On Mon, Mar 19, 2018 at 7:57 PM, Ron Buckton wrote: >>

RE: Pointers

> -Original Message- > From: es-discuss On Behalf Of Isiah > Meadows > Sent: Monday, March 19, 2018 3:21 PM > To: Michael J. Ryan > Cc: es-discuss > Subject: Re: Pointers > > And even if we *could* get pointers

Re: Pointers

Pointers are also useful for microoptimization of stepping through arrays... but it wouldn't help JS without a lot of work in the engines... for( var x = 0; x < width*height; x++ ) { arr[x] = 3; } - var ptr = arr; for( var x = 0; x < width*height; x++ ) { ptr[0] = 3; ptr++; }

Re: Pointers

And even if we *could* get pointers into JS, I'd *strongly* not want it to be like what's proposed here. Instead, I'd prefer an object encapsulating a reference to a variable, something like this (although engines could avoid the ceremony of closures here): ```js let foo = 1; func(ref foo, bar)

Re: JSON.canonicalize()

JSON is utf-8 ... As far as 16 but coffee points, there are still astral character pairs. Binary data should be enclosed to avoid this, such as with base-64. On Fri, Mar 16, 2018, 09:23 Mike Samuel wrote: > > > On Fri, Mar 16, 2018 at 11:38 AM, C. Scott Ananian

Re: Pointers

Please no, mutable objects are bad enough imho. On Mon, Mar 19, 2018, 12:47 Sebastian Malton wrote: > Proposal: > Add a new variable-esk type called pointer which acts sort of like a > reference to the data which it has been assigned to but modifies also the > original

Pointers

Proposal:Add a new variable-esk type called pointer which acts sort of like a reference to the data which it has been assigned to but modifies also the original reference when modified. Justification:When working with objects in particular it is often useful for satiny reasons to use local

Re: weakref proposal update

er, by "it looks larger than it appears" I meant "it's smaller than it appears" or "it looks much larger than it is" or some such :). On Mon, Mar 19, 2018 at 5:21 PM, Dean Tribble wrote: > A first round of spec-text is now pushed for the new APIs at >

Re: weakref proposal update

A first round of spec-text is now pushed for the new APIs at https://github.com/tc39/proposal-weakrefs/blob/master/specs/spec.md. A note on the API change in the last presentation: it looks larger than it appears. 1) Some of WeakRef was pushed in to a new parent, "WeakCell", so that it could

Re: JSON.canonicalize()

On Mon, Mar 19, 2018 at 10:30 AM, Anders Rundgren < anders.rundgren@gmail.com> wrote: > On 2018-03-19 15:17, Mike Samuel wrote: > >> >> >> On Mon, Mar 19, 2018 at 9:53 AM, Anders Rundgren < >> anders.rundgren@gmail.com > >> wrote: >> >> On

Re: JSON.canonicalize()

On 2018-03-19 15:17, Mike Samuel wrote: On Mon, Mar 19, 2018 at 9:53 AM, Anders Rundgren > wrote: On 2018-03-19 14:34, Mike Samuel wrote: How does the transform you propose differ from?

Re: Arbitrary precision numbers in JSON

On Mon, Mar 19, 2018 at 10:09 AM, Anders Rundgren < anders.rundgren@gmail.com> wrote: > On 2018-03-19 14:43, Mike Samuel wrote: > >> Maybe have a parser function that receive the text of the number? If no >> callout is specified, it could throw an appropriate error. >> >>

Re: JSON.canonicalize()

On Mon, Mar 19, 2018 at 9:53 AM, Anders Rundgren < anders.rundgren@gmail.com> wrote: > On 2018-03-19 14:34, Mike Samuel wrote: > >> How does the transform you propose differ from? >> >> JSON.canonicalize = (x) => JSON.stringify( >> x, >> (_, x) => { >>if (x && typeof x ===

Re: Arbitrary precision numbers in JSON

On 2018-03-19 14:43, Mike Samuel wrote: Maybe have a parser function that receive the text of the number?  If no callout is specified, it could throw an appropriate error.     JSON.safeParse(json, optionalReviver, optionalParseUnrepresentable) That would allow it to tie into future proposals

Re: Arbitrary precision numbers in JSON

On 2018-03-19 14:43, Mike Samuel wrote: Maybe have a parser function that receive the text of the number?  If no callout is specified, it could throw an appropriate error.     JSON.safeParse(json, optionalReviver, optionalParseUnrepresentable) That would allow it to tie into future proposals

Re: JSON.canonicalize()

On 2018-03-19 14:34, Mike Samuel wrote: How does the transform you propose differ from? JSON.canonicalize = (x) => JSON.stringify(     x,     (_, x) => {       if (x && typeof x === 'object' && !Array.isArray(x)) {         const sorted = {}         for (let key of

Re: Arbitrary precision numbers in JSON

Maybe have a parser function that receive the text of the number? If no callout is specified, it could throw an appropriate error. JSON.safeParse(json, optionalReviver, optionalParseUnrepresentable) That would allow it to tie into future proposals like decimal, and in conjunction with a

Re: JSON.canonicalize()

How does the transform you propose differ from? JSON.canonicalize = (x) => JSON.stringify( x, (_, x) => { if (x && typeof x === 'object' && !Array.isArray(x)) { const sorted = {} for (let key of Object.getOwnPropertyNames(x).sort()) { sorted[key] = x[key]

Re: add reverse() method to strings

yep agreed...that's not enough reason (I just added that might be "the reason for..."). Cheers. [ ]s *--* *Felipe N. Moura* Web Developer, Google Developer Expert , Founder of BrazilJS and Nasc

Re: Arbitrary precision numbers in JSON

On 2018-03-19 08:23, Michał Wadas wrote: It's workaround. I forgot to mention that if you overload the "Number" type with int64's, BigNum's, BigInt's etc. you will need a mapping scheme so that the parser knows what to look for and create. OTOH, mapping from a string literal using the

Re: add reverse() method to strings

> > The only reason I would defend the "reverse" method in strings is because it > makes sense. > I think JavaScript is very intuitive, and, as Arrays do have the "reverse" > method, that simply makes sense to have it in strings as well. > ”Making sense” and ”symmetry of API” is not a

Re: Arbitrary precision numbers in JSON

On 2018-03-19 08:23, Michał Wadas wrote: It's workaround. JSON.parse can't properly parse valid JSON subset. ZIP codes are not part of JSON specification, arbitrary precision numbers are (and JSONs with 64-bit ints are widely used). Well, you have an comrade at Google (Mike Samuels) who

Re: Arbitrary precision numbers in JSON

It's workaround. JSON.parse can't properly parse valid JSON subset. ZIP codes are not part of JSON specification, arbitrary precision numbers are (and JSONs with 64-bit ints are widely used). Modyfing schema is possible only if you control it and control all of its consumers. BigInt proposal

Re: Arbitrary precision numbers in JSON

On 2018-03-19 07:32, Michał Wadas wrote: Yeah, there are workarounds for passing bigints. Unfortunately, it's workaround, and it doesn't solve the problem - certain valid JSONs can't be properly used in ECMAScript without writing JSON parser in user land. Hi Michal, I wouldn't call it a

Re: Arbitrary precision numbers in JSON

Yeah, there are workarounds for passing bigints. Unfortunately, it's workaround, and it doesn't solve the problem - certain valid JSONs can't be properly used in ECMAScript without writing JSON parser in user land. On Mon, 19 Mar 2018, 03:33 Anders Rundgren,