when
your result promise is cancelled.
Bergi
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Dean Landolt schrieb:
On Wed, Feb 25, 2015 at 2:39 PM, Bergi wrote:
If you are using generators for async, then you'd call `return()` when
your result promise is cancelled.
That seems a bit surprising to me -- I'd expect a cancelled promise to
result in some kind of exception be
Kevin Smith schrieb:
Should have been:
source.next(dataView) -> Promise>
which you kind of need anyway ; )
Wouldn't `.next()` rather need to return an
IteratorResult>?
Bergi
___
es-discuss mailing list
es-discuss@moz
nc-iteration/
Oh, right, I should've read your first post properly - you were talking
about future *asynchronous* generators.
Bergi
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
rray to `.includes` is rather
meaningless (not denotative).
If we need a method to do this (to allow for native optimisations with
fancy string search algorithms), I'd suggest to use a different method
name like `String.prototype.includesAll`.
Bergi
___
e for Object.assign.
It uses an ":=" operator, so your example would read
obj1 := {x, y};
Bergi
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
ittedly, I think arrow functions have same problem. How is
var y = (a) => a ? f : x++ (1);
evaluated (or is it syntactically valid at all)?
Bergi
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
property that it call
`.return()` on the iterator when `n` values have been taken out of it.
Bergi
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
iterator.throw(e);
done = true;
} else
throw e;
} finally {
if (!done)
iterator.return();
}
Bergi
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Axel Rauschmayer wrote:
Given that redundant calls to `return()` don’t make a difference (h/t Bergi)
I'm sorry, that was not 100% accurate. I only referred to `.return(x)`
returning {done:true, value:x} and `.throw(e)` being equivalent to
`throw e;` when the generator was never started
es that, how often is
it forgotten?
Bergi
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
which sets the respective [[Iterated*]]
internal property to `undefined`?
Bergi
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
absorbing element
<https://en.wikipedia.org/wiki/Absorbing_element> would benefit from this.
Bergi
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
ctive that would be very similar to your async
functions. It has a nice example of such an unexpected race condition.
Kind regards,
Bergi
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
or a particular test case,
this example
<https://github.com/ELLIOTTCABLE/from/blob/fb19155abbf39e91a532537599d3d16f592e16b6/lib/from-new.js#L96>
is not).
Bergi
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
ilarly, we remove step 6 ("*Order the elements of names so they are
in the same relative order as would be produced by the Iterator that
would be returned if the [[Enumerate]] internal method was invoked on
O.*") from `EnumerableOwnNames` (`Obj
istinction between ordered and
unordered dictionaries somewhere, with tooling supporting both versions.
Instead of stuffing everything into objects.
How does an algorithm know whether to use `==`, `===`, `Object.is`,
`Object.isSameOrdered`, `Object.equals`…?
Bergi
(sorry if this came off as a r
would
test for it twice, which even gives way to fulfilling promises with
thenables - if only the `then` method is attached to your object after
you have resolved your promise with it. Which could cause some quite
unexpected results.
Bergi
___
es
Allen Wirfs-Brock schrieb:
feel free to file a ES7 bug saying that such inconsistent terminology usage
should be eliminated.
[X] Done: https://bugs.ecmascript.org/show_bug.cgi?id=4328
Bergi
___
es-discuss mailing list
es-discuss@mozilla.org
ype
property.
(at least that's how I understood super references)
Bergi
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
No, it must return a new object every time.
See
https://esdiscuss.org/topic/performance-of-iterator-next-as-specified
for the last discussion on this.
Bergi
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es
ation order.
So this is parsed to
(((arr)[((i)++)])=((obj)[(e)]))
and then basically evaluated left-to-right.
Bergi
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
thing :-)
Yes, it will need a while until people get accustomed to that.
Bergi
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
natively just use a single equals sign with a parameter list:
let f(x) = y
let f() = y
(which almost looks like Haskell, hehe).
Bergi
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
more than single
identifier. The basic examples from your motivation could easily handled
by this, withoug looking much worse:
let pickedObj = {o.p1, o.p2}; // uses "p1" and "p2" for property names
{pickedObj.p3} = o; // takes "p3"
on.sent), yield* g2];
}())
with `Iterable> -> Generator>`?
Bergi
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
(well,
multiple ones actually), it's not worth the trouble of introducing a new
operator.
Bergi
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
shadowing, you could break out of that.
Bergi
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
e
loaders, but at least at the top level of an app this would certainly be
useful.
While `JSON.parse(await fs.readFile("options.json"))` could trivially be
replaced with `fs.readFileSync`, such might not be the case for `await
db.readTable("con
arbitrary assignments). Your example code would look like this:
let someObj = { doStuff(){} };
let doStuff = ::someObj.doStuff;
doStuff();
Bergi
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
tor](factory) { return [factory()]; }
};
const WithOptions = (...args) => ({
[Symbol.extractor](factory) { return [factory(...args)]; }
});
import NoOptions(A) from "a";
import WithOptions("config")(A) from "a";
, allowing us to get the key values of them, but this
syntax does not allow us to extract the value for a given key from
somewhere in the map.
Predictability is all fine, but I still consider maps to be inherently
unordered.
Bergi
___
es-discuss mai
ot;destructuring" factory functions
(by applying them), though I don't know whether that's the best solution
for this `import` problem.
Bergi
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
that's semantically sound.
We then could consider an iterator to be "not matching" if any of the
target elements are left `undefined`, i.e. when the iterator is
exhausted before all elements have gotten a value, similar to default
initialisers are handled
sider
new Map(Object.entries({a: 1, b: 2}))
and
new Map(Object.entries({b: 2, a: 1}))
to be equivalent for all purposes of an algorithm that uses commutative
operators.
Bergi
___
es-discuss mailing list
es-discuss@mozilla.org
https://m
0is%20'%2F'>.
But if you're that much inclined to save single characters, I'd
recommend to use
```js
s = s.slice(s[0] == '/');
```
Bergi
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
esis. But
that's no improvement over the current `Math.pow`.
Bergi
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
, not
the function call one.
Regards,
Bergi
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
g would be what I'd envision to solve your problem:
```js
// does work
lazy sumOfSquares = compose(sum, squares);
lazy sum = reduce((x, y) => x + y, 0);
lazy squares = map(x => x * x);
```
where `lazy` would work pretty much like a `lazy val` in Scala.
Regards,
Bergi
_
d to the instance.
It's indeed super-confusing to "declare" such methods right inside the
`class` though, that's why I'm really opposing that proposal
(https://github.com/jeffmo/es-class-static-properties-and-fields).
Greetings,
Bergi
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
ld be
quite confusing. Creating the generator explicitly is a better idea.
And as kevin said, you still can return generators from your getters
manually if you really want that.
Regards,
Bergi
___
es-discuss mailing list
es-discuss@mozilla.org
le {
// a getter on the prototype
get myListener() {
// with per-instance memoisation
return this.myListener = (…) => {
// that returns a bound method
…
};
}
}
```
It might be equivalently done via a custom decorator of course:
```js
class Xample {
@autobind
myListener(…
rson extends … {
constructor(name) {
super(name);
this.greet = () => {
return this.name + " says hi!";
};
}
}
```
vs
```js
class Person extends … { // with default constructor
::greet() {
return this.name + " says hi!";
}
}
```
Regards,
Bergi
* methods as well.
I don't get that argument. Doesn't `start`/`end` exactly do that: ignore
the locale? It always trims/pads at the start/end of the string,
regardless whether that will be rendered to the left or right of the screen?
Bergi
mething in front of it or cut something at the
beginning, regardless whether your iterator does iterate your array or
structure backwards (right-to-left?), from left to right, top-down,
bottom-up, or whatever direction you've drawn/imagined it in.
Bergi
instead of buffers (or efficiently creating buffers from
strings), we'd need to introduce something like ConstTypedArrays.
Regards,
Bergi
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
sometimes not are already known to be an antipattern. Making this
obscurely dependent on some fragile syntactic conditions could only make
this worse.
If you want to migrate your library to asynchrony, just make it a
breaking change. Your consumers will thank you for it.
Kind regards,
Bergi
var classReference = {Paintbrush, …}[className];
var instance = new classReference();
For additional security, you might want to use an object that doesn't
inherit from `Object.prototype`, or just a `Map` right away.
Regards,
Bergi
__
ould be obscure. Sometimes I *want* to export promises without anyone
awaiting them. And of course, exports do resolve to variable bindings,
not to values, so this would be hard to align with the current spec.
Regards,
Bergi
___
es-discuss mailing
Fabrício Matté schrieb:
Btw, the term "IIAFE" should probably be avoided, as the "A" can
ambiguously mean "Arrow" or "Async".
I've never heard of an "Arrow function expression" - it's just "arrow
function" :-)
I th
This would break much more than a `last` getter/method or `nth`/`at` method.
Arrays becoming callable would mean that their `typeof` changes from
`"object"` to `"function"`, which is a very bad idea.
Regards,
Bergi
___
es-d
. I wonder if this is
an intended behavior? Thanks in advance.
Yes, it is intended, and pretty intuitive - default initialisers are
evaluated in the scope of the called function, at the call - they're not
values that are computed at the time of the definit
t if you have an empty
object constant, which is statically attached to the function instance
instead of being re-evaluated at every call, that would surely cause
enough havoc already :-)
Regards,
Bergi
___
es-discuss mailing list
es-discuss@mozill
the colon fits
better than the dot here.
Regards,
Bergi
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
they only will start or continue using
it in new code.
Even in code examples, or simple demonstrations, use `console.log(x,
Object.getPrototypeOf(x))` over `console.log(x, x.__proto__)`.
Regards,
Bergi
PS: Ceterum censeo __proto__ esse delendum :-)
,
Bergi
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Viktor Kronvall schrieb:
What would this do?
```
let newObj = {obj.a.b}
```
`{a: {b: obj.a.b}}`
or
`{a: obj.a.b}`?
Or should nested property access be disallowed?
Neither - `obj.a.b` is `(obj.a).b`, so it's equivalent to `let newObj =
{b: obj.a.b}`.
The spec would basically be something lik
d reject promise with an informative TypeError as the
| reason.
Regards,
Bergi
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
together via `Object.keys`/`Object.getOwnProperty…`.
The last case is the only one where you'd really need `hasOwnProperty`.
The proliferation of `if (obj.hasOwnProperty(key))` needs to be stopped,
it's cargo cult programming at best.
Regards,
Bergi
___
it that a test `if (…sort[Symbol.isStable])` will
yield a falsy default value (`undefined`) in legacy implementations.
Regards,
Bergi
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
ven that some of the methods
are duplicated between `Object` and `Reflect`) and one would expect that
they do the same or at least have a similar purpose.
You seem to be proposing something completly different that has nothing
to do with creation.
Kind regards,
Bergi
__
e` is
that we create an logical instance, but not an actual object like
`Object.create` does.
Sorry, you lost me here again.
Bergi
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
ge.
We still don't understand how your `Reflect.create` is supposed to work
or be implemented, how it is different from the old approach, and what
exactly its advantage(s) will be.
Kind regards,
Bergi
___
es-discuss mailing list
es-
/ -
which contains an empty class that never matches anything, which is
followed by a literal "]".
Kind regards,
Bergi
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
fied code) and use the same
name for a parameter b) it should not fail in real-world engines even if
the spec says something else.
Regards,
Bergi
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
mporting-a-function-expression-or-a-function-declaration-from-a-ES6-module.
Kind regards,
Bergi
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
[dynamicName]: class {
…
}
};
but I can see absolutely no reason why you'd want to put a class inside
an object literal.
Bergi
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
much easier ways to do that:
let x = class {
get name() {
return dynamicName;
}
…
};
or
class x {
…
}
Object.defineProperty(x, "name", { value: dynamicName });
Kind regards,
Bergi
___
es-discuss mailing list
;d need to use
`Object.setPrototype` as there is currently no declarative way other
than `class`es to define functions with custom prototypes.
In methods, there would need to be a way to populate the [[HomeObject]]
other than declaring the method as part of a clas
quot;home"/"found" object? That's a
no-no for obvious reasons.
Kind regards,
Bergi
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
omposable syntax to developers, and gives more
predicability with cancellation semantics that are easier to reason about.
If you want a particular behaviour from Domenics proposal, you still can
model it fairly easy with explicit rejections; In contrast, you can't
get the behaviour I desire
I am searching for a champion to present this proposal as a strawman to
TC39.
I would like to get an official feedback from the committee, as Domenic
seems unwilling to incorporate my fundamentally different ideas into his
proposal.
Looking forward to see you step up,
Bergi
Why would `tmp` be stored as the [[HomeObject]] when the function
doesn't use `super`? In that case a [[HomeObject]] is not needed at all.
kind regards,
Bergi
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
rtial application operator to make this syntax useful?
I guess the discussions from
https://github.com/tc39/proposal-bind-operator/issues/35 and
https://github.com/tc39/proposal-bind-operator/issues/26 are relevant here.
Kind regards,
Bergi
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
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
ammar ambiguities, and no completely new
productions, but I believe it would help a great deal.
Yes, one would still have to repeat the name of the object to/from which
the properties to assign/take, but that's usually rather short so it's
not a large burden.
I could create a proposal r
27;s a bit sad that I don't see how to get to renaming and defaults with
this syntax.
Renaming has always been part of the language:
```
o2 = {y: o1.x} // o2.y = o1.x
({y: o2.z} = o1); // o2.z = o1.y
```
and with destructuring we'd also get defaults.
- Bergi
___
, so this does formally apply some common sense :-)
kind regards,
Bergi
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
cord, would they? Take `ReturnIfAbrupt` as an example.
It's weird.
- Bergi
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
What you call "one more point" already exists as the `await` keyword and
is much more powerful than a limited `.return` operator:
<https://github.com/tc39/ecmascript-asyncawait>
Please make sure to be familiar with the topic before making further
prop
confusion and usually a bad idea.
Why not simply use a function `b()` that you can call? It's clear what
happens with that.
We hardly need a special syntax for getter/setter variables in lexical
scopes.
- Bergi
___
es-discuss mailing list
es-di
at at least has to wrap the result in `{value: …,
done:true}` would always have to stay on the stack.
However, it would be possible to do tail-recursive calls in generator
functions via
return yield* f(…)
Kind regards,
Bergi
___
es-discuss mailing
ssion.
- Bergi
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
easons why this is a bad idea?
As you already said, it would break a great lot of code.
- Bergi
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
rejection,
but those are usually exceptions you *don't expect* so you might not
need to deal with them at all.
- Bergi
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
f you don't care
about other realms).
Ooops, `Object.getPrototypeOf(o) === Object.prototype` is what I meant.
- Bergi
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
ncellable promises automatically.
This very much reminds me of my own ideas
https://github.com/bergus/promise-cancellation/blob/master/enhancements.md
:-)
kind regards,
Bergi
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
third parameter.
kind regards,
Bergi
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
ops, but
still at least the functions themselves will consume memory. For the
simple programmer, we need an automatic (not error-prone) unsubscription
mechanism once the respective cancellable operation ended.
Kind regards,
Bergi
--
Of course, my own proposal
<htt
Jan-Ivar Bruaroey wrote:
On 10/27/16 4:25 PM, Bergi wrote:
I'd however love to be able to cancel specific chaining operations,
i.e. `then` callbacks.
If you try the fiddle - http://jsfiddle.net/jib1/jz33qs32/ - you'll see
cancelling terminates the chain. If you intersperse non-c
? { prop: value } : null);
```
Or depending on your condition, also just `cond && { prop: value }`.
The object spread proposal will achieve the same, without the need for
any extra operator.
- Bergi
___
es-discuss mailing list
es-discuss@mozilla.o
can easily just use `String`.
Kind regards,
Bergi
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
modulos of the passed
values; if you really wanted to completely omit passed values you'd
rather overwrite the `.from` method as a whole instead of relying on the
inherited one.
Bergi
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
llable: a no-op function. This might lead to subtle bugs, where
`super()` was intended to call the parent class's method, but does
nothing - not even throwing an error!
Should an exception been thrown if the `func` returned by
`GetSuperConstructor()` is `%FunctionPrototyp
Allen Wirfs-Brock schrieb:
On Dec 16, 2014, at 1:18 PM, Bergi wrote:
...
I've read <https://esdiscuss.org/topic/referencing-super> and it seems that needing to
call `super.describe()`/`super.render()`/`super.say()` is intended behaviour. I'm fine with
that, as explici
he class fields proposal and an arrow function.
However, [there are many problems with that
approach](https://medium.com/@charpeni/arrow-functions-in-class-properties-might-not-be-as-great-as-we-think-3b3551c440b1)
anyway.
kind regards,
Bergi
___
es-discu
to say is that your proposed alternative has exactly
the same problems as instance-member arrow functions have today.
Best regards,
Bergi
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
xactly the same function that is passed in all three cases. There
is no instance bound to `f`, and `f(event)` will not invoke it as a
method (with a receiver/`this` value).
Best regards,
Bergi
___
es-discuss mailing list
es-discuss@mozilla
ooling could then use these
annotations according to its own rules.
kind regards,
Bergi
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
developer productivity.
kind regards,
Bergi
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
1 - 100 of 122 matches
Mail list logo
