ell.
Or are you asking for a jsdoc-like thing that lives in comments, where
the code can be run without a compilation step?
kind regards,
Bergi
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
would need to match, and an import map would be prevented from swapping
out the module under your hands.
kind regards,
Bergi
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
intelligent in that regard.
best,
Bergi
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
}
}
return Function(scope, `
function ${name}(${args.join(", ")}) {
${body}
}
return ${name};
`)(...values);
};
const foo = makeFunction("foo", [], "console.log(x)", {x: 10})
foo(); // logs 10
```
kind regards,
Bergi
be just
```
let a = 1;
console.log(a)
a = 2;
```
kind regards,
Bergi
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
e trivial
cases where an array is filled gradually to produce the more efficient
representation.
kind regards,
Bergi
[1]: it probably isn't:
https://stackoverflow.com/questions/54481918/#comment95848513_54485509
___
es-discuss mailing list
es-discuss@mo
.setEncoding('buffer').toArray())
```
```js
// It's different for each database
const [item] = await db.scan({
filter: {key: value},
limit: 1,
}).toArray()
```
kind regards,
Bergi
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail
it is. Doing stuff concurrently *is*
fundamentally different from doing it serially, and should be reasoned
about every time you use it.
kind regards,
Bergi
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
not provide
backwards compatibility.
kind regards,
Bergi
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
cks.
kind regards,
Bergi
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
ishable from
```
for (const x of [1,2,3])
_ if (x % 2)
_ console.log('odd')
_ console.log(x)
```
(and no, please don't suggest repetion of whatever token you come up
with for signifying nesting level)
kind regards,
Bergi
___
es-discuss mailing lis
, most importantly it doesn't
offer any declarations.
kind regards,
Bergi
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
the existing proposal at
<https://github.com/tc39/proposal-iterator-helpers>. You then can write
const b = Array.from(a.values().filter(…).map(…))
or
for (const x of a.values().filter(…).map(…))
console.log(x);
kind regards,
Bergi
tely need this functionality, use `.then(r=>[,r],e=>[e])`
in your code, or put it inside a helper function. (Or use one from a
library like <https://github.com/scopsy/await-to-js/>).
We do not need this as a method in the EcmaScript standard.
best regards,
Bergi
_
oper productivity.
kind regards,
Bergi
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
e 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
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.org
https
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
ass 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-discuss ma
`String`.
Kind regards,
Bergi
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
? { 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
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-cancellable
ves 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
<https://github.com/bergus/promise-cancellation> is the
third parameter.
kind regards,
Bergi
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
utomatically.
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
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
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
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
.
- Bergi
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
that 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 list
of 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-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
ke `ReturnIfAbrupt` as an example.
It's weird.
- Bergi
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
formally apply some common sense :-)
kind regards,
Bergi
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
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
___
es-discuss mai
nd 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 repo, who would like to help?
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.org
https
erator 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
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
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
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 with Domenics approach.
Feedback here on the mailing list and at the repo is warmly welcome.
Ber
quot;/"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
d 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 class/object l
, there are 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
[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
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
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
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-discuss@mozilla.org
https
ogical 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
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
___
es-d
[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
`/`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
___
es-discuss mailing list
es-discuss
and 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
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
,
Bergi
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
ing
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 :-)
___
es-discuss mailing list
es-disc
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
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@mozil
ded 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 definition of the function.
Regards,
Be
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-discuss mai
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 think it wou
. 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 list
es-discuss
r 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
___
es-d
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
and
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
t something 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
__
* 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
___
es
/ 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(…) {…}
}
```
Re
uctor(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
_
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
https
in fact be bound 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
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
__
with parenthesis. 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
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
with computed
keys?
To me, there is not much difference between
let o = {
method: () = {…}
};
and
let o = {};
o.method = () = {…};
yet the first function gets a name while the second one doesn't.
Bergi
___
es-discuss mailing list
es
declarations over unnamed function expressions myself, but for named arrow
functions this seems like a good idea. And browsers are doing it already anyway
for a better debugging experience. Regardless, it's in ES6 now, I just wondered
why it's not as consistent as I expected it to be.
Bergi
. It's
anonymous, and will stay so.
You see, no magic! :-)
Bergi
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
false). Everything else had already been abstracted out enough :-)
What do you think, can we fix this? Do I need to make a more explicit proposal?
Bergi
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
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 mailing list
es-discuss
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
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 today.
Do you think that is viable?
Bergi
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://mail.mozilla.org
WithOptions = (...args) = ({
[Symbol.extractor](factory) { return [factory(...args)]; }
});
import NoOptions(A) from a;
import WithOptions(config)(A) from a;
// A === moduleInstance
What do you think about that?
Bergi
___
es
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
), yield* g2];
}())
with `IterableGeneratori, o, r - Generatori, o, Iterabler`?
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
could break out of that.
Bergi
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
. 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 as property name, assigns to LHS
`pickedObj.p3`
Bergi
, 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
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
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
on the stack.
Can you give me an example? Did I miss something?
Thanks,
Bergi
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
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
. (If it wrapped the resolve
handler, we should resolve the value again indeed).
regards,
Bergi
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
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 rant. I know it cannot
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
are welcome.
Bergi
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
.
Similarly, 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` (`Object.keys`)?
Bergi
` when no `this` value
is supplied (throw only if it's there, but not an object and constructor
function)?
Or is this considered to be too error-prone with Promise subclassing, where
`.then(MyCustomPromise.reject)` would not work as expected (fail silently)?
regards,
Bergi
-new.js#L96
is not).
Bergi
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
1 - 100 of 116 matches
Mail list logo
