Funny to see the issue is still discussed, I've actually used WeakSets a
bunch in the last few years.
Here's code from last weak that detects with a mutation observer when a new
iframe is
attached to the DOM (simplified):
https://gist.github.com/benjamingr/9afb875d1d87377e7e66b166cf1905b5
___
Addressing the original request:
> Any chance something like Node's process.nextTick could be added, maybe
something like Promise.schedule(func, thisArg, ...args)?
That's basically `Promise.resolve().then(func.bind(thisArg, ...args))`
Although promise schedulers are huge - and I think could solv
ure what would be better.
>
> On Fri, Jan 6, 2017, 04:38 Benjamin Gruenbaum
> wrote:
>
>> Oh, Bluebird's `Promise.using` does that with very high certainly. The
>> reason we introduced `using` rather than let people just use the disposer
>> pattern is because it i
e
> rest should be closed either immediately or as soon as they are
> available, to avoid resource leaks.)
> -
>
> Isiah Meadows
> m...@isiahmeadows.com
>
>
> On Mon, Jan 2, 2017 at 10:04 AM, Benjamin Gruenbaum
> wrote:
> > And, on a similar note
And, on a similar note - a pattern has emerged in userland libraries all
over:
http://stackoverflow.com/questions/28915677/what-is-the-promise-disposer-pattern
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Hey,
We've actually worked on this extensively in bluebird with
http://bluebirdjs.com/docs/api/promise.using.html and disposers which give
something similar to the `with` syntax you describe.
There has also been work on a `defer` like abstraction. The tricky parts
were mostly getting it to work w
Hey,
I remember a lot of talk about adding `.map/.filter` etc to iterators. The
benefits of doing this are pretty big and I think fairly well understood
and several other proposals (like observables and async iterators) would
benefit from it.
(I expand on the big advantages this has over Array#ma
I see some discussion is happening - that's good.
As I don't want to see the tremendous amount of work people put into value
types and operator overloading go to waste - let's bring Brendan and
Christian into this discussion and start with a link to Brendan's 2013
slides:
http://www.slideshare.ne
First of all - when you engage the list in that manner do not expect super
constructive responses. Be concise and direct about what you want to get at
and you'll get a response.
Disrespect members - and people will not be so willing to engage.
As for language feature proposal - the process is out
Note that there is no guarantee that the `then` handlers (after the await)
will fire in the same loop since they defer execution on their own and
might defer it further.
In practice I assume they'll probe to see if they need to actually schedule
asynchronously or the constructed promise is already
> async functions only address the async use case and they're all scheduled
on a simple micro-task queue. We need fine grained control over scheduling.
Perhaps Zones can help a bit with that but that's just one of severals
concepts that need this.
Isn't the problem we actually need to solve here t
ng/es-observable
>
> On Mon, Mar 14, 2016, 16:01 Benjamin Gruenbaum wrote:
>
>> I would be super surprised if I could use `var` everywhere _except_ async
>> iteration.
>>
>> So I'd say consistency triumphs. Same reason all the ES2015 features
>> exist in
I would be super surprised if I could use `var` everywhere _except_ async
iteration.
So I'd say consistency triumphs. Same reason all the ES2015 features exist in
non-strict mode.
Also, you might want to look at the async/await pep for why Python has added
async iteration in 3.5
> On 14 Mar
Thanks Raul, I understand this case better now - fixed in master
https://github.com/petkaantonov/bluebird/commit/7094e1677d79de99ba5f268785f49e9d99508e2f
- wasn't particularly hard to fix this case, no one ever complained about
it or mentioned it before so it wasn't considered.
Bluebird will now
, Benjamin Gruenbaum
wrote:
> For what it's worth, bluebird promises detect the error and reject with:
>
> ```
> TypeError: Chaining cycle detected for promise #
> ```
>
> So it's both possible and not a performance issue. For this case, a
> WeakMap is not needed f
For what it's worth, bluebird promises detect the error and reject with:
```
TypeError: Chaining cycle detected for promise #
```
So it's both possible and not a performance issue. For this case, a WeakMap
is not needed for this case. https://jsfiddle.net/41ez2b6d/ .
> We ran into code "in the
on refcounting are completely different: they are
> precise, prompt, predictable, and deterministic.
>
>
>
> On Wed, Feb 17, 2016 at 12:59 AM, Benjamin Gruenbaum > wrote:
>
>>
>>
>> On Wed, Feb 17, 2016 at 10:51 AM, Andreas Rossberg
>> wrote:
>>
>
On Wed, Feb 17, 2016 at 10:51 AM, Andreas Rossberg
wrote:
> On 17 February 2016 at 09:40, Benjamin Gruenbaum
> wrote:
>
>> If you starve a generator it's not going to get completed, just like
>>> other control flow won't.
>>>
>>
>> I
On Wed, Feb 17, 2016 at 10:28 AM, Andreas Rossberg
wrote:
>
> The spec does not talk about GC, but in typical implementations you should
> expect yes.
>
Yes, important point since some ECMAScript implementations don't even have
GC and are just run to completion. The spec doesn't require cleanup.
In the following example:
```js
function* foo() {
try {
yield 1;
} finally {
cleanup();
}
}
(function() {
var f = foo();
f.next();
// never reference f again
})()
```
- Is the iterator created by the function `foo` ever eligible for garbage
collection?
- If it
For what it's worth very popular templating libraries like KnockoutJS use
`woth` heavily.
I think the consensus is that writing DSLs should be done as a transformation
into JavaScript (like JSX) and not inside JavaScript (like Knockout and your
library)
The dynamic nature of `with` is why it i
Hey, I just wanted to point out that this is now discussed in
https://github.com/groundwater/nodejs-symposiums/pull/5
It appears that there are no proposals on the way to deal with it and it is
a very real problem. What would be the correct process to bring more
attention to it?
On Fri, Nov 22, 2
*F# cancellation* - on second thought implicit cancellation through
cancellation like in F# is impractical because of the eagerness of
promises. I don't think it's a valid alternative here. I've discussed this
with Reed Copsey (an F# expert) and he explained the philosophy behind it
to me - it does
> Another cancellation scenario is when the consumer of an asynchronous
task no longer
> needs the result of an operation. In this case, they will only have
access to the Promise
> unless the cancellation token is routed to them through some other path.
For what it's worth - this is exactly how pr
> We could use a promise subclass as the cancellation token, but then
tokens (and their constructor) would inherit things that really don't make
sense, like "CancelToken.resolve" and "CancelToken.prototype.catch".
Generally I dislike inheritance. I was merely saying it's an option. I
favor composi
> Cool, I'm aware that cancellable promises have been explored in depth.
I'd prefer to keep this thread focused on cancellation tokens though, and
avoid comparisons.
Cool, re-reading the discussion you asked for this in the first message - I
apologize for missing it.
I think using promises as tok
We have pretty sound cancellation semantics in bluebird 3.
http://bluebirdjs.com/docs/api/cancellation.html
Handles multiple subscribers soundly. Solves the common use cases pretty well -
has absolutely zero magic and pretty simple semantics. They work with .all and
.race too.
We have had a
factoring more brittle.
>
> —Claude
>
> > Le 5 oct. 2015 à 16:04, Benjamin Gruenbaum a
> écrit :
> >
> > Hey, other languages with default parameter values like Python, C#, Ruby
> and PHP have a means to retrieve the default parameter values of a function.
> >
Hey, other languages with default parameter values like Python, C#, Ruby
and PHP have a means to retrieve the default parameter values of a function.
>From what I understand (correct me if I'm wrong) - there is no way to get
the default values of a parameter of a function in JavaScript. For exampl
On Sat, Oct 3, 2015 at 6:00 PM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:
> well
>
> > In fact, oftentimes the way people code uses closures which tend to be
> more expensive than creating promises anyway.
>
> you pass "closures" to create a promise, a then and a catch, not sure
> w
On Sat, Oct 3, 2015 at 5:37 PM, 韩冬 wrote:
>
> This is exactly where i’m getting puzzled, suppose we have thread in
> javascript(or whatever to run different things on different cores),
> consider following code:
>
>
We don't have threads in JavaScript, and there is no shared memory in most
curre
for continuation based solutions:
> - Complex sementics.
> - No memorization(can be done by other ways).
>
> Do you agree with me on this summary? and suppose in future javascript
> will get multicore support, will the state-machine based solution subject
> to r
> Where do you get the courage to challenge every inventor that they have
to learn everything you've learned before they making decisions?
Can we please keep it civil?
> the question is why not check other languages first, when there’re nice
solutions already there.
Promises are rooted in the 1
e.log(o[sym].name);
> ```
>
> Currently it appears Babel outputs an empty string for this case.
>
> If the current spec handles symbols just fine in this way, why would "the
> possibility that the property key is a symbol" be a reason for an
> expression form not to set
> On Sun, Jul 26, 2015 at 8:48 PM, Allen Wirfs-Brock
> wrote:
>
>>
>> On Jul 26, 2015, at 5:11 AM, Benjamin Gruenbaum wrote:
>>
>> > In theory this sounds like a cool idea, I didn't even know variable
>> assignments named functions.
>> >
>
In theory this sounds like a cool idea, I didn't even know variable
assignments named functions.
The only issue I see here is how we're now differentiating assignment by
where it happens - what if the property is computed? As far as I know
function names are more constrained (like variable names)
I just want to point out you can use esdiscuss.org today for that form of
viewing. No need to switch platforms for it.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
> Out of curiosity, can you give an example of the Not Good parts? ISTM the
await prefix is more of an explicit cast than an implicit conversation, and
other than the very small timing gap in how throws are handled I pointed
out a few days ago, I can't think of any situations where a throw would
ma
If we _wanted_ to add named parameters, we would _probably_ have a
_different_ name for the named parameter inside the function and outside
the function.
```js
function foo(x as y){
}
foo(y = 5);
```
Or something like that. That said, I'm not convinced we _need_ named
parameters, that they just
Ok, thanks, that clarifies it.
On Mon, Jul 13, 2015 at 12:14 AM, Allen Wirfs-Brock
wrote:
>
> On Jul 12, 2015, at 1:48 AM, Benjamin Gruenbaum wrote:
>
> I think my original post might have been confusing so allow me to clarify.
>
> I'm not suggesting to add named parame
Thanks for the clarification.
On Sun, Jul 12, 2015 at 5:05 PM, Luke Scott wrote:
>
> On Jul 12, 2015, at 2:48 AM, Benjamin Gruenbaum
> wrote:
>
> I think my original post might have been confusing so allow me to
> clarify.
>
> I'm not suggesting to add named
I think my original post might have been confusing so allow me to clarify.
I'm not suggesting to add named parameters to the language, I did not
intend to start a discussion about named parameters' merits vs passing an
object literal (I thing Axel had a blog about that a while ago).
What I'm inte
foo({ bar: 5 })
>
> function foo ({ baz, bak, bar }) {
> console.log(bar)
> }
>
> Or is there anything else you are considering or something I am missing.
>
> Regards
>
> > On Jul 12, 2015, at 6:47 AM, Benjamin Gruenbaum
> wrote:
> >
>
Hey, I wasn't able to find information about the current status of a named
parameters propsosal:
// as in:
foo(bar = 5); // logs 5
function foo(baz, bak, bar){
console.log(bar);
}
Is this being considered? Was it decided for/against? Anyone working on it?
___
de facto
> extension point, can we protect that more narrowly?
> --scott
> On Jul 6, 2015 1:56 AM, "Benjamin Gruenbaum" wrote:
>
>> So, following work on RegExp.escape [1] I found out that implementations
>> may extend the regular expression grammar in JavaScript
So, following work on RegExp.escape [1] I found out that implementations
may extend the regular expression grammar in JavaScript [2]. However, when
asking esdiscuss and Stack Overflow about it [2][3] it doesn't look like
any implementations currently do so (*).
Can we please forbid implementations
The reason ECMAScript 2015 promises do not have `finally` is because it
wasn't necessary for the initial proposal and things were 'running late'
already and it was possible to ship without it. Shipping fast enabled us to
include promises in ECMAScript 2015.
It is entirely possible (and dare I say
ve brought up is a closed mailing list or discourse board.
On Wed, Jul 1, 2015 at 9:35 PM, Allen Wirfs-Brock
wrote:
>
> On Jul 1, 2015, at 5:37 AM, Benjamin Gruenbaum wrote:
>
> So, this is something that has been bothering me for a while now.
>
> The TC, and the maili
l 1, 2015 at 4:15 PM, Andreas Rossberg
wrote:
> On 1 July 2015 at 14:37, Benjamin Gruenbaum wrote:
>
>> So, this is something that has been bothering me for a while now.
>>
>> The TC, and the mailing list is full of some really smart people.
>> However, smart peop
So, this is something that has been bothering me for a while now.
The TC, and the mailing list is full of some really smart people. However,
smart people can overlook things too and smart people can spend months in a
debate that other people already thought about.
Other languages have open proces
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}`)`
On Tue, Jun 30, 2015 at 10:35 AM, Mathias Bynens wrote:
> On Mon, Jun 29, 2015 at 9:04 PM, Benjamin Gruenbaum
> wrote:
> > Why? What adv
Why? What advantage would it offer?
On Mon, Jun 29, 2015 at 9:49 PM, C. Scott Ananian
wrote:
> 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
I meant something like `RegExp.escape(str, "☺")` (also escapes `☺`). Since
strings are iterable by code points via the new iteration protocol this
sounds like the natural choice. I'm not sure such a second argument would
be a good idea.
On Mon, Jun 29, 2015 at 9:42 PM, C. Scott Ananian
wrote:
>
This is currently discussed at
https://github.com/benjamingr/RegExp.escape/issues/29#issuecomment-116789780
.
Adding my comment from there to here too:
Some languages (PHP for example) do this (optional parameter with
additional parameters) so it's not unprecedented.
The question we should ask o
string to eval (yes/no)?
And so on.
On Sat, Jun 20, 2015 at 2:07 PM, Benjamin Gruenbaum
wrote:
> As a cross-cutting concern I'd like the feedback of more people on
> https://github.com/benjamingr/RegExp.escape/issues/29
>
> Basically we've got to make a design choice of re
Quoting the specification at
http://www.ecma-international.org/ecma-262/6.0/index.html#sec-literals-regular-expression-literals
:
"
An implementation may extend the ECMAScript Regular Expression grammar
defined in 21.2.1, but it must not extend the RegularExpressionBody and
RegularExpressionFlags
Why is this a comment on the RegExp.escape discussion?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
As a cross-cutting concern I'd like the feedback of more people on
https://github.com/benjamingr/RegExp.escape/issues/29
Basically we've got to make a design choice of readable output vs.
potentially safer output.
___
es-discuss mailing list
es-discuss@m
> I agree completely, and I fully apologize. Starting the thread this way
was inappropriate, at least without some mitigating text which I did not
think to add. I like the fact that we are all civil to each other here and
try to keep the environment welcoming and friendly. Please no one take my
mes
Some comments:
> { p1 as x, p2 } # o // { x: o.p1, p2: o.p2 }
Not sure why the `as` syntax since we already have `x : p1 ` syntax from
destructuring.
> p # if o
This is really complicated syntax, especially given `if` is not an
expression.
> { a, b } @ [ 1, 2 ] // { a: 1, b: 2 }
A second o
be directed
> at its apparent lack of deprecation strategy, rather than shutting down
> discussion of new ideas that might help us write better programs.
>
> Just my 2p.
>
>
>
>
> On Thursday, June 18, 2015, Allen Wirfs-Brock
> wrote:
>
>>
>> On Jun 18, 2015
mmarchi <
andrea.giammar...@gmail.com> wrote:
> > And I occasionally have to go and look up details.
>
> You know nothing Allen Wirfs-Brock (cit)
>
> On Thu, Jun 18, 2015 at 8:55 PM, Allen Wirfs-Brock
> wrote:
>
>>
>> On Jun 18, 2015, at 12:18 PM, Andr
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
> From: Kyle Simpson
To: "es-discuss@mozilla.org"
Cc:
Date: Thu, 18 Jun 2015 07:34:28 -0500
Subject: Re: revive let blocks
> > (function (a, b, c) {
> >
> > }(2))
> The main disadvantage of that style over the one I'm advocating for is
that it visually separates the variable declaration (`a`) fr
Apart from complicating the engine and the grammar - what advantage does the
second version have over the first one? Why do you prefer it to the first one?
(Genuinely asking)
I'm also not aware of any other languages that provide this (although that's
not a huge issue).
> On Jun 18, 2015, at
me.
>
>
>
>
> On Wed, Jun 17, 2015 at 10:19 AM, Benjamin Gruenbaum
> wrote:
>
>> > congratulations and THANK YOU! I learned something important reading
>> your messages. The notion that we can preserve non-observability when
>> making one thing a WeakMap
t; `WeakMap` key? That would return a realm-specific object, of course.
>
>> On Wed, Jun 17, 2015 at 10:19 AM, Benjamin Gruenbaum
>> wrote:
>> > congratulations and THANK YOU! I learned something important reading your
>> > messages. The notion that we can p
> congratulations and THANK YOU! I learned something important reading your
> messages. The notion that we can preserve non-observability when making one
> thing a WeakMap iff we make all other WeakMaps be strong for those same
> objects is true, novel, and very surprising. I have been working o
This is awesome news - now to get someone to make something similar to
es5.github.io in terms of readability and ease of use :)
> On Jun 17, 2015, at 19:46, Allen Wirfs-Brock wrote:
>
> Ecma international has announced that its General Assembly has approved
> ECMA-262-6 The ECMAScript 2015 Lan
Aren't WeakMap keys only objects?
> On Jun 17, 2015, at 19:18, Mark S. Miller wrote:
>
> [+Allen]
>
> Can registered Symbols be used as keys in WeakMaps? If so, we have a fatal
> unauthorized communications channel that we need to fix in the spec asap!
>
>
>
___
Pointing out that I'm replying to a message with an empty subject - using
the correct original title here
-- Forwarded message --
From: Rock
Benjamin Gruenaum, Andrea Giammarchi, you are wrong about RegExp:
```js
var re = /./;
new RegExp(re) === re; // false
RegExp(re) === re; //
idering a bit of `as if` to allow implementations to, for
example, not escape some characters inside `[...]` as long as the end
result is the same.
On Sat, Jun 13, 2015 at 9:57 PM, Mark S. Miller wrote:
> On Sat, Jun 13, 2015 at 11:39 AM, Benjamin Gruenbaum > wrote:
>
>> On Sat, J
hese subclasses?
>
> This is hacky, but in my code I just did `argument.exec ? treatAsRegExp :
treatAsString`.
>
>
>
>>
>>
>> *From:* es-discuss [mailto:es-discuss-boun...@mozilla.org] *On Behalf Of
>> *Mark S. Miller
>> *Sent:* Saturday, June 13,
Ok, with a ton of help from Domenic I've put up
http://benjamingr.github.io/RexExp.escape/
Less cool coloring but more links and motivating examples and so on at
https://github.com/benjamingr/RexExp.escape
As this is my first attempt at this sort of thing - any non-bikeshed
feedback would be appr
I'm going to address your questions.
`Object.is` - have you checked and read the actual thread in the list
explaining the motivation behind that?
"Operator [] casts its argument to string ... but not when used with
Symbol" - that's the poit of symbols - to have non string keys that are
unique. Re
Yes, don't make the distinction and instead run only promises - provide a
function that takes a sequence and returns a promise over it. Not every
iterable sequence is a sequence of async values.
> On Mar 3, 2015, at 22:54, Dean Landolt wrote:
>
> One use case is for coroutine runners which acc
Sorry, forgot to CC the list
> From: Benjamin Gruenbaum
> Date: February 12, 2015 at 22:19:14 GMT+2
> To: Domenic Denicola
> Subject: Re: about lightweight traits
>
> Those points are good, let me try to address them
>
> State - In other languages like C# and swi
Why does ES even need traits?
The only aspect they can help with here is the type system we don't have yet.
We have `Object.assign` that works fantastically for most classic trait use
cases.
> On Feb 12, 2015, at 18:35, Andrea Giammarchi
> wrote:
>
> Without going down full specification/impl
Never been a need?
Why if you want to use objects as keys and not use reference equality? We've
been over this.
Here's a ref
https://mail.mozilla.org/pipermail/es-discuss/2014-February/036389.html
> On Dec 8, 2014, at 23:46, Tab Atkins Jr. wrote:
>
>> On Thu, Dec 4, 2014 at 9:46 PM, Katelyn
Correct, I mean value types (or objects) that have value semantics and support
operator overloading.
> On Nov 19, 2014, at 06:31, Katelyn Gadd wrote:
>
> You don't mean typed objects, right? You mean value types, pass-by-value?
>
> -kg
>
>> On 18 November 2014 02:36, Benjamin (Inglor) Gruenba
In my year long experience with large code bases using Bluebird promises which
do unhandled rejection tracking - I haven't had a single false positive or
false negative.
Adding error handlers asynchronously is in practice extremely rare.
> On Nov 12, 2014, at 19:15, James Long wrote:
>
> On W
Just as a note - I think that if we learned anything in this regard it's that
standards should guide and not dictate.
It׳s rather impossible to break reasonable user level code and I don't think
it's reasonable to expect developers to be fortune tellers :)
(I like the idea though)
> On Oct 19
82 matches
Mail list logo
