Is there any way to access `new.target` using ES5 syntax?
It appears that the "correct" way to create a subclass using ES5 syntax is:
```
function MyPromise(executor) {
var self = Reflect.construct(Promise, [executor], new.target);
return self;
}
Object.setPrototypeOf(MyPromise, Promise);
```
On Fri, Apr 24, 2015 at 10:46 AM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:
> So you should do the same with Promise methods but then you'll see overall
> a quite consistent performance drop when using all these subclasses.
>
Well, not exactly. The Promise methods are all written t
On Fri, Apr 24, 2015 at 11:31 AM, C. Scott Ananian
wrote:
> On Fri, Apr 24, 2015 at 10:46 AM, Andrea Giammarchi <
> andrea.giammar...@gmail.com> wrote:
>
>> So you should do the same with Promise methods but then you'll see
>> overall a quite consistent perfo
Inadvertently moved discussion off-list; requoting on list:
On Sat, Apr 25, 2015 at 4:33 PM, Domenic Denicola wrote:
> From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of C.
> Scott Ananian
>
> > But in the code given previously, I've used `Objec
On Sat, Apr 25, 2015 at 5:03 PM, Domenic Denicola wrote:
> There needs to be an unforgable brand property such that only objects
> created with `new XPromise()` pass `XPromise.resolve`. It is not a use case
> to allow building an object ES5 style in pieces to pass the brand check.
> Such objects
On Sat, Apr 25, 2015 at 6:58 PM, Kevin Smith wrote:
> I think I'd rather see `Promise.resolve` changed to use `this.constructor`
>> instead of `this.[[PromiseConstructor]]`, like every other Promise-related
>> method. Can someone who feels strongly otherwise give me the use case for
>> `[[Promis
On Sun, Apr 26, 2015 at 12:56 AM, Domenic Denicola wrote:
> It's possible Reflect.construct has introduced a security hole that was
> not present before the recent instantiation reform. Hopefully Mark can
> comment more.
>
Note that, even without `Reflect.construct`:
```
x = new C(); // C some
On Tue, Apr 28, 2015 at 2:41 PM, Allen Wirfs-Brock
wrote:
> So, ES6 Promises reflect a specific set of design decisions, including a
> specific definition of "same type" that appears to exist solely for use by
> Promise.resolve. All that design guarantees is that the object has an
> certain spec
On Wed, Apr 29, 2015 at 1:06 AM, Brendan Eich wrote:
> Kevin Smith wrote:
>
>> So what would the ideal Promise.resolve semantics do? I'm not sure,
>> maybe use SpeciesConstructor instead of [[PromiseConstructor]]?
>>
>
> This removes the wart in my view, has no less integrity. C. Scott?
Making
Aren't there limits to the number of arguments you can pass to a ES
function before getting a stack overflow?
I've gotten in trouble trying to abuse the `arguments` array like this
before, for example `Math.max.apply(Math, someVeryLargeArray)`.
Empirically, with iojs 1.8.1:
```
> Math.max.apply(M
On Wed, Apr 29, 2015 at 12:49 PM, Allen Wirfs-Brock
wrote:
> On Apr 29, 2015, at 8:44 AM, C. Scott Ananian wrote:
>
On Wed, Apr 29, 2015 at 1:06 AM, Brendan Eich wrote:
>
> Kevin Smith wrote:
>>
>>> So what would the ideal Promise.resolve semantics do?
On Wed, Apr 29, 2015 at 1:00 PM, Mark S. Miller wrote:
> The invariant I am interested in:
>
> In a realm where we (the trusted defender who runs first) make Promise
> defensive as follows
>
> * Freeze everything primordial, as SES does
>
> * Make a DefensivePromise subclass of Promise that diffe
On Wed, Apr 29, 2015 at 12:56 PM, Allen Wirfs-Brock
wrote:
> On Apr 29, 2015, at 9:04 AM, C. Scott Ananian wrote:
> > I suppose it would be nice if JavaScript engines fell back to passing
> arguments on the heap to avoid this problem, but I don't think that's part
&g
On Wed, Apr 29, 2015 at 1:37 PM, Mark S. Miller wrote:
> On Wed, Apr 29, 2015 at 10:26 AM, C. Scott Ananian
> wrote:
>
>> On Wed, Apr 29, 2015 at 1:00 PM, Mark S. Miller
>> wrote:
>>
>>> The invariant I am interested in:
>>>
>>> In a rea
On Wed, Apr 29, 2015 at 2:07 PM, Mark S. Miller wrote:
> Hi Scott, I think your approach is on the right track. How about the
> following?
>
> Anyone see a way to attack it?
>
>
>
> const goodPromises = new WeakSet();
> class DefensivePromise {
> constructor(x) {
> super(x);
> if (new.t
```
constructor(x) {
super(x);
Object.defineProperties(this, { then: { value: this.then }});
Object.freeze(this);
if (this.constructor==DefensivePromise && this.then ===
DefensivePromise.prototype.then) {
goodPromises.add(this);
}
}
```
Getting closer, I hope!
> I al
On Wed, Apr 29, 2015 at 3:09 PM, Allen Wirfs-Brock
wrote:
> class DefensivePromise extends Promise {
> constructor(x) {
> super(x);
> if (new.target === DefensivePromise) {
>
// I'm assuming this test is just to be subclass friendly and
allow subclasses to freeze later?
>
On Wed, Apr 29, 2015 at 3:32 PM, Allen Wirfs-Brock
wrote:
> On Apr 29, 2015, at 12:24 PM, C. Scott Ananian wrote:
>
> On Wed, Apr 29, 2015 at 3:09 PM, Allen Wirfs-Brock
> wrote:
>
>> class DefensivePromise extends Promise {
>> constructor(x) {
>>
On Wed, Apr 29, 2015 at 4:16 PM, Allen Wirfs-Brock
wrote:
> On Apr 29, 2015, at 12:40 PM, C. Scott Ananian wrote:
>
> On Wed, Apr 29, 2015 at 3:32 PM, Allen Wirfs-Brock
> wrote:
>
>> On Apr 29, 2015, at 12:24 PM, C. Scott Ananian wrote:
>>
>> On Wed, Apr 29, 2
On Mon, Feb 23, 2015 at 3:31 PM, Mark S. Miller wrote:
> On Mon, Feb 23, 2015 at 11:59 AM, Isiah Meadows
> wrote:
>>
>> On Feb 23, 2015 6:06 AM, "Andrea Giammarchi"
>> wrote:
>>
>> > On Sun, Feb 22, 2015 at 11:18 PM, Jordan Harband
>> wrote:
>>
> [...]
>
>> >> - We'd definitely want `Map.empt
On Wed, Apr 29, 2015 at 6:32 PM, Allen Wirfs-Brock
wrote:
> The "another test" that you propose seems to be exactly the fix which
> Brandon proposed and I codified, to wit:
>
> 2. If IsPromise(x) is true,
>> a. Let constructor be the value of SpeciesConstructor(x, %Promise%)
>> b. If Same
f the collections.
>
> I welcome proposals that would make sense for JavaScript.
>
>
>
> On Thu, Apr 30, 2015 at 9:52 AM, C. Scott Ananian
> wrote:
>
>> On Mon, Feb 23, 2015 at 3:31 PM, Mark S. Miller
>> wrote:
>>
>>> On Mon, Feb 23, 2015 at 11:
On Thu, Apr 30, 2015 at 2:22 PM, Mark S. Miller wrote:
> It would also not be compatible with ES6 code. SES will be freezing Map,
> Set, WeakMap, and WeakSet instances in order to tamper proof their API. I
> expect many others will as well. Having this freeze then cause a
> non-mutability in ES7
o Map. If you subclass it, freeze it,
override set/delete/etc it is still possible to mutate the map using
`Map.set.call(m, 'a', 'b');`. And there is no way for use code to get at
the [[MapData]] slot to protect it.
--scott
On Thu, Apr 30, 2015 at 2:42 PM, C. Scott Anan
I like the idea of snapshot methods, but they can be implemented in user
code using subclasses in ES6. I'm particularly interested in the "lock
down in place" mechanism because it *cannot* be implemented in user code.
And yes, if we had it all to do over again, it would have been nice if the
Map
On Thu, Apr 30, 2015 at 5:57 PM, Jordan Harband wrote:
> I don't see how it would be possible in ES6 user code to ever make a
> Map/Set or a Map/Set subclass instance immutable, since
> `Map.prototype.set.call`/`Set.prototype.add.call` will operate on any
> Map/Set-like object's `[[MapData]]`/`[[
Hopefully everyone has had a little bit of time to think over the
issues with Promise.resolve().
Last week I proposed three different reasonable semantics for
`Promise.resolve`, none of which involve the `[[PromiseConstructor]]`
internal field:
https://esdiscuss.org/topic/subclassing-es6-objects-w
On Tue, May 19, 2015 at 12:24 PM, Steve Fink wrote:
> That visually collides with destructuring for me.
>
> let [a, b] = foo();
> let {a, b} = foo();
> let f(a, b) = foo(); # Very different
>
> I almost expect that last one to use f as a custom matcher of some sort,
> given the previous two.
We
Why not just use a subclass of Promise? I don't see why that has to be
part of the base class.
```
class ObservablePromise extends Promise {}
ObservablePromise.prototype.isSettled = function() { return
!!this.isSettled; };
ObservablePromise.prototype.then = function(res, rej) {
return super.the
Thanks! It looks like core-js has already patched in the new spec:
https://github.com/zloirock/core-js/issues/75
I've opened https://github.com/paulmillr/es6-shim/issues/344 on es6-shim,
and I'll see if I can get a patch together for it.
I've filed https://bugzilla.mozilla.org/show_bug.cgi?id=11
`Promise.resolve` doesn't use the species pattern any more:
https://esdiscuss.org/topic/fixing-promise-resolve
The rationale was that `resolve` is more like a constructor than a mutator.
I don't have a strong opinion about `Promise.all`, but I think perhaps it
would be better if none of the static
Mark: I outlined two of these use cases in
https://esdiscuss.org/topic/subclassing-es6-objects-with-es5-syntax#content-50
One is `WeakPromise` which is a promise holding a weak reference to its
resolved value. This is the closest analogy with the canonical Smalltalk
motivating example for species
On Tue, Jun 9, 2015 at 11:11 AM, Mark S. Miller wrote:
> Ok, thanks for the example. I understand your rationale. This is what I
> asked for but not what I was really looking for. Can we come up with an
> example where class and species usefully differ where neither is Promise?
> IOW, where the s
Mark: The `prfun` library in fact uses `Promise#timeout(n)` instead of a
`TimeoutPromise` subclass. But this is really a language-design question.
You might as well ask why we have `WeakMap()` as a constructor instead of
using `Map#weak()` or `weakmapify(map)`. The fundamental reason is "so you
c
Promise subclassing is super useful. `prfun` uses it extensively: first to
override the global `Promise` to avoid polluting the global namespace, and
then secondly to implement features like `Promise#bind`. I've also used it
experimentally to implement "functional" promises (with a `Promise#chain
On Tue, Jun 9, 2015 at 12:38 PM, Mark S. Miller wrote:
> On Tue, Jun 9, 2015 at 9:29 AM, C. Scott Ananian
> wrote:
>
>> Mark: The `prfun` library in fact uses `Promise#timeout(n)` instead of a
>> `TimeoutPromise` subclass. But this is really a language-design question.
On Tue, Jun 9, 2015 at 12:38 PM, Mark S. Miller wrote:
> Do you ever test that the object returned by `Promise#timeout(n)` is
> something other than a plain promise?
>
Responded on the other thread.
Let's keep this one focused on: do we need to tweak the definitions of
`Promise.all` and `Promis
> rej(v) );
}
}
```
--scott
On Tue, Jun 9, 2015 at 12:56 PM, Mark S. Miller wrote:
>
>
> On Tue, Jun 9, 2015 at 9:35 AM, C. Scott Ananian
> wrote:
>
>> Promise subclassing is super useful. `prfun` uses it extensively: first
>> to override the global `Promise` to
On Tue, Jun 9, 2015 at 1:43 PM, Mark S. Miller wrote:
> On Tue, Jun 9, 2015 at 10:38 AM, C. Scott Ananian
> wrote:
>
>> I think that Promise pipelining works just fine -- you just have to
>> implement it inside Promise#get, Promise#put, etc.
>> ```
>> // This i
On Tue, Jun 9, 2015 at 3:45 PM, Mark Miller wrote:
> I don't understand your answer. p and r are plain promises. They must be
> because they exist before q does. q is the first remote promise in this
> scenario. How does resolving r to q leave r unsettled but give q access to
> the messages buffe
On Wed, Jun 10, 2015 at 10:37 AM, Allen Wirfs-Brock
wrote:
> However, I think that Promise.reject should parallel Promise.resolve and
> hence it should not use species.
>
I agree.
--scott
___
es-discuss mailing list
es-discuss@mozilla.org
https://mai
@Domenic: please see the previous discussion at
https://esdiscuss.org/topic/subclassing-es6-objects-with-es5-syntax#content-50
since there is much more discussion back-and-forth there.
And you are correct about Promise.reject; Allen is proposing to remove the
@@species from that method as well.
T
I don't agree that @@species is useful at all for changing constructor
signatures, since there is no closure argument.
If we had dynamically scoped variables, then:
```
LabelledPromise[Symbol.species] = function() { return
LabelledPromise.bind(label/*dynamically scoped*/); };
function() {
On Wed, Jun 10, 2015 at 11:46 AM, Domenic Denicola wrote:
> Regardless of whether or not you agree, that was the original motivation
> for its introduction.
>
https://twitter.com/awbjs/status/535962895532584960 says:
> ES6 final tweaks #8: Smalltalk-like species pattern used in Array methods,
@Alexander Jones: no new syntax is needed to implement what you want; we
already have Template Strings. For example, you could define a new
function `RegExp.join` (which takes either an array or a string as its
first argument, see below):
```
var pattern = RegExp.join`^(abc${ "someString, escaped
On Sat, Jun 13, 2015 at 1:51 AM, Mark S. Miller wrote:
> Nice! Inspired
>
> // Based on
> // https://github.com/benjamingr/RexExp.escape/blob/master/polyfill.js
> function re(template, ...subs) {
> const parts = [];
> const numSubs = subs.length;
> for (let i = 0; i < numSubs; i
To throw some more paint on the bikeshed:
The "instanceof RegExp" and "RegExp(...)" parts of the "perfect"
implementation of `RegExp.tag` should also be fixed to play nicely with
species.
I think Allen and I would say that you should *not* use the species pattern
for instantiating the new regexp
Could you include some examples of *calling* functions defined this way?
The most obvious way uses `Function#call` and would be terribly awkward.
Perhaps I'm just overlooking some ES6 feature which makes passing a
specific `this` value easy?
It seems curious that you are not using methods instead
Filed Pull Requests to es6-shim and core-js to match the late change to the
`Promise.reject` text.
Yay final spec!
--scott
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
It seem semi-obligatory at this point to cite "Growing a Language", by Guy
Steele.
https://www.youtube.com/watch?v=_ahvzDzKdB0
Transcript at http://www.cs.virginia.edu/~evans/cs655/readings/steele.pdf
(if you must).
I tend to agree with the idea that at this point we need *means to grow
syntax* ra
An interesting wrinkle in language design has been the rise of
sophisticated linting and style tools like `jscs`. If you wish to
deprecate `var` for instance, it is straightforward to write a jscs module
to enforce that. Further, several large communities (node, wikipedia, etc)
have published jsc
No, thank you.
Email clients are the ultimate forum aggregators.
--scott
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
I think you will note that many of the "built in" methods in the spec are
already implemented in JavaScript code in many implementations (v8,
firefox). Similarly the ability to implement more fundamental features in
terms of macro definitions may well be pursued by the implementations. But
note
It's not too surprising: it's the same reason why the ES6 spec was just
published *on paper*, with the html version being explicitly flagged as
non-normative.
For standards work, having a reliable substrate is important. It is not
the TC's job to innovate on or experiment with collaboration platf
Please, not an iterable over characters. (Or at least, "not only".) Use a
RegExp. Imagine trying to ensure that any characters over \u007f were
escaped. You don't want an iterable over ~64k characters.
In addition, a RegExp would allow you to concisely specify "hex digits, but
only at the start
And I'm suggesting that `RegExp.escape(str, /[image: ☺]/ug)` is a much
better idea.
--scott
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On Tue, Jun 30, 2015 at 3:46 AM, Benjamin Gruenbaum
wrote:
> I'm still not sure if it's worth it, after all it's just sugar for
> `RegExp.escape(str).replace(/[a-z]/gu, m => `\\${m}`)`
>
I think you're making my point! And I hope your version of `RegExp.escape`
doesn't use hexadecimal or unicod
But the design might work well as a proxy object? It could delegate
to the "real" object, with its private slots, after that object is
created.
--scott
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On Wed, Jul 1, 2015 at 9:22 AM, Alex Kocharin wrote:
> People regularly suggest borrowing concepts from different languages here
> (we got arrow functions from coffee, generators are from python I believe).
>
And `@@species` is from smalltalk. (More or less.)
Lots of smalltalk influence, actu
You can get `Promise #finally` by using a helper library, like `prfun`.
But the finally method in particular has a quirk, see the end of:
https://github.com/cscott/prfun/blob/master/README.md#promisefinallyfunction-handler--promise
It would be nice to resolve that properly before standardization.
I think it would be more worthwhile of we tried to draw a compatibility
boundary. Taking perlre as a baseline, for example, are there additional
characters we should escape in `RegExp.escape` so that implementations (and
the language itself) could add more perlre features without breaking
compatib
outside
> the process. Basically, we take the ECMAScript regular expression object as
> specified (minus allowing extensions) as our base line :)
>
>
> Cheers,
> Benji
>
>
> On Mon, Jul 6, 2015 at 5:03 PM, C. Scott Ananian
> wrote:
>>
>> I think it would
And --- apologies for continuing to beat this drum --- you can look at the
`prfun` package on npm for a practical example of this use of Promise
subclasses and `resolve`.
If other folks know of other libraries using these features, let me know so
I can recommend other people's code as well as my o
`fesetround` would be a terrible way for JavaScript to implement this, as
it would allow a piece of code to affect the behavior of completely
unrelated pieces of code by screwing with global rounding mode bits.
That's not going to happen.
I believe there have been proposals to allow greater access
up
float".
--scott
On Wed, Aug 26, 2015 at 12:01 PM, Martin von Gagern
wrote:
> Hello Scott,
>
> Thanks for the comment!
>
> On 26.08.2015 17:22, C. Scott Ananian wrote:
> > `fesetround` would be a terrible way for JavaScript to implement this,
>
> I agree, the
IMO promises should reject if they are "cancelled". The same method that
gave you the Promise (for example, an AJAX API) can give you a capability
to "cancel" the Promise, ie cancel the pending network operation and reject
the Promise (rejecting is a no-op if the operation races with cancellation
As referenced in the cited thread
(https://esdiscuss.org/topic/performpromiseall#content-6) there are
actually two uses of the Promise constructor in the definition of
`all` and `race`. To quote myself:
> [N]ote that the implementations given for `Promise.all` and `Promise.race`
> use Promises i
Without rehashing the previous discussion, I totally disagree. Having
`Promise#resolve()` go through `@@species` made it totally useless. It's
also not in the spirit of the smalltalk species, which used very narrowly
for instance methods like `map`, not for constructors.
--scott
___
(Sorry, that should have been `Promise.resolve`, not `Promise#resolve`.)
--scott
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Again, the reasoning at the time was that `Promise.all(x)` could be
considered sugar for `Promise.resolve(x).all()` in ES7, and so
`Promise.all` was "really" an instance method after all. Again, I could
support a change, I'm just saying it wasn't totally crazy, and no one made
any objection at the
The spec has been implemented as is by both `es6-shim` and `core-js`, and
there are plenty of users of these. So it's not correct to say that it
hasn't been implemented yet; folks aren't waiting for the browsers.
The differing behaviors in the null-or-undefined case should probably be
remedied, a
If you're using string templates, why not do the full regex there,
instead of just passing the result to `new RegExp`?
See https://esdiscuss.org/topic/regexp-escape#content-22 and
https://esdiscuss.org/topic/regexp-escape#content-28 for some
examples, and
https://github.com/benjamingr/RegExp.esca
We have a template string mechanism, and it allows linefeeds. Let's
use that, instead of inventing new heredoc syntax.
--scott
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On Fri, Nov 6, 2015 at 1:20 PM, Brian Terlson
wrote:
> RegExp.re or similar seems nice:
>
> ```
> let re = RegExp.re("x")`
> (\d{3}-)? # area code (optional)
> \d{3}-# prefix
> \d{4} # line number
> `;
> ```
>
> But it seems like previous proposals of this want escaping which d
sensus has been reached (except perhaps by default, since no one has
advocated for alternatives).
--scott
On 11/4/15 11:22 PM, C. Scott Ananian wrote:
> see my previous message for the exact wording proposal which
> changes step 6.
>
https://esdiscuss.org/topic/performpromiseall#content-6
On Wed, Nov 18, 2015 at 6:50 PM, Domenic Denicola wrote:
> All uses of @@species are to be removed from Promise.race and Promise.all.
> The committee achieved consensus on this, without you.
>
To be precise, steps 3-5 are to be removed entirely from Promise.all
(25.4.4.1) and Promise.race (25.4.
On Wed, May 21, 2014 at 8:33 AM, Claude Pache
wrote:
>
> I have thought about the right semantics (and the issues) of the
> existential operator.
>
> user.getPlan?().value?.score;
>
> The intended semantics of `?` is that, whenever its LHS evaluates to
> `null` or `undefined`,
> the evaluatio
`arr.slice(-1)[0]` does what you want, I think.
--scott
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Here's a quick plug for my `prfun` library (https://github.com/cscott/prfun)
which implements this as `Promise.delay(1000)`.
API at:
https://github.com/cscott/prfun#promisedelaydynamic-value-int-ms--promise
You can also do `return somepromise.delay(100)` which resolves to the same
value as `samep
Promise dispatch should actually simplify to this in certain common cases.
I meant to write up a document describing the typical dispatch
optimizations high-performance Promise libraries do, based on my
experiences writing https://github.com/cscott/babybird (although
Optimization Notes in the READM
See http://wiki.laptop.org/go/Canonical_JSON -- you should probably at
least mention unicode normalization of strings. You probably should also
specify a validator: it doesn't matter if you emit canonical JSON if you
can tweak the hash of the value by feeding non-canonical JSON as an input.
--sc
trict mode for
JSON.stringify().
--scott
On Fri, Mar 16, 2018 at 4:48 AM, Anders Rundgren <
anders.rundgren....@gmail.com> wrote:
> On 2018-03-16 08:52, C. Scott Ananian wrote:
>
>> See http://wiki.laptop.org/go/Canonical_JSON -- you should probably at
>> least
>>
On Fri, Mar 16, 2018 at 12:23 PM, Mike Samuel wrote:
>
>
> On Fri, Mar 16, 2018 at 11:38 AM, C. Scott Ananian
> wrote:
>
>> Canonical JSON is often used to imply a security property: two JSON blobs
>> with identical contents are expected to have identical canoni
On Fri, Mar 16, 2018 at 1:30 PM, Anders Rundgren <
anders.rundgren@gmail.com> wrote:
> On 2018-03-16 18:04, Mike Samuel wrote:
>
> It is entirely unsuitable to embedding in HTML or XML though.
>> IIUC, with an implementation based on this
>>
>>JSON.canonicalize(JSON.stringify("")) === `""`
And just to be clear: I'm all for standardizing a canonical JSON form. In
addition to my 11-year-old attempt, there have been countless others, and
still no *standard*. I just want us to learn from the previous attempts
and try to make something at least as good as everything which has come
befor
I think the horse is out of the barn re hashable-vs-canonical. It has
(independently) been invented and named canonical JSON many many times,
starting 11 years ago.
https://gibson042.github.io/canonicaljson-spec/
https://www.npmjs.com/package/another-json
https://www.npmjs.com/package/canonical-j
On Fri, Mar 16, 2018 at 4:07 PM, Anders Rundgren <
anders.rundgren@gmail.com> wrote:
> Perfection is often the enemy of good.
>
So, to be clear: you don't plan on actually incorporating any feedback into
your proposal, since it's already "good"?
--scott
_
My main feedback is that since this topic has been covered so many times in
the past, any serious standardization proposal should include a section
surveying existing "canonical JSON" standards and implementations and
comparing the proposed standard with prior work. A standard should be a
"best of
On Sun, Mar 18, 2018, 10:30 AM Anders Rundgren <
anders.rundgren@gmail.com> wrote:
> Violently agree but do not understand (I guess I'm just dumb...) why (for
> example) sorting on UCS2/UTF-16 Code Units would not achieve the same goal
> (although the result would differ).
>
Because there are
On Fri, Mar 16, 2018 at 9:42 PM, Anders Rundgren <
anders.rundgren@gmail.com> wrote:
> Scott A:
> https://en.wikipedia.org/wiki/Security_level
> "For example, SHA-256 offers 128-bit collision resistance"
> That is, the claims that there are cryptographic issues w.r.t. to Unicode
> Normalizatio
tt
On Sun, Mar 18, 2018, 2:48 PM Anders Rundgren
wrote:
> On 2018-03-18 19:08, C. Scott Ananian wrote:
> > On Fri, Mar 16, 2018 at 9:42 PM, Anders Rundgren <
> anders.rundgren@gmail.com <mailto:anders.rundgren@gmail.com>>
> wrote:
> >
> >
This is the parsing side equivalent to "canonicalized". Any
security-sensitive application of "canonical JSON" should have a strict
verifier confirming that the input is canonical; this verifier would
presumably also throw for out-of-range numbers as you suggest.
--scott
On Sun, Mar 18, 2018, 9
To be super explicit: given an array 'a', then: `Array.from(a).sort()` will
return you a sorted clone. That works even if `a` has an iterator or is an
array-like object. That's just seven characters longer than
`Array.sort(a)`, which is what you seem to be proposing.
To be sure, I don't think th
"keyword function" might not be too bad, either...
--scott
On Sat, Apr 7, 2018 at 2:32 PM, Naveen Chawla wrote:
> "function" function is the best out of all of the alternatives you
> mentioned.
>
> "Anonymous function declared with the function keyword" if it's not too
> wordy.
>
> On Sat, 7 Ap
For your consideration, here is an implementation of Monadic Promises,
as a Promise subclass:
(This version is inexpertly hand-rewritten into ES6; see
https://gist.github.com/cscott/b1966d485807d9a8cc39 for an ES5 version
which has been tested to work against
https://github.com/paulmillr/es6-shim/
And, if you like the division between `then` and `chain`:
class MonadicPromise extends Promise {
constructor(exec) {
class MP extends MonadicPromise {
constructor(exec) {
Promise.call(this, (f,r) => exec( v => f([v]), r));
}
}
ret
Note that `Array.from(str)` and `str[Symbol.iterator]` overlap
significantly. In particular, it's somewhat awkward to iterate over
code points using `String#symbolAt`; it's much easier to use
`substr()` and then use the StringIterator.
--scott
ps. I see that Domenic has said something similar.
Yes, I know what `String#at` is supposed to do.
I was pointing out that `String#at` makes it easy to do the wrong
thing. If you do `Array.from(str)` then you suddenly have a complete
random-access data structure where you can find out the number of code
points in the String, iterate it in reverse
My goal was simply to see how feasible it was to write a "autoboxing"
Promise subclass that could be used for async maps, the Service Worker
API, etc. It turns out that the subclass is quite small and
straightforward, although Promise.all() and Promise.race() won't work
as-is on these "monadic" pr
Can someone point me to the spec for `System.import`?
https://github.com/jorendorff/js-loaders/blob/master/browser-loader.js
doesn't seem to include it.
It seems to me that it would be worthwhile to ensure that
`System.import` had good semantics. It would allow a nice migration
path for existing
1 - 100 of 258 matches
Mail list logo
