I’m not sure it’s okay to reply on this very old thread, but if I’m
understanding correctly the desugared code can be fairly short with new
Object.getOwnPropertyDescriptors:
```js
function partial(base, extension) {
extension.prototype.__proto__ = base.prototype.__proto__; // to enable
'super
Is the only problem here is the parser problem with `obj.prop?.2:.1`? Then how
about `??. ` instead of `?.`?
>Once upon a time, there was a fascinating proposal on this subject:
Why are you posting twice? :/
___
es-discuss mailing list
es-discuss@mozi
You’re right, my `partial` function does not support multiple inheritance and
the input class should not have its own prototype chain. I think partial class
and multiple inheritance are two different issues, however, as the former can
work without the latter and vice versa.
Or `!.`, which unfortunately is now being used by TypeScript?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
>The token ?. works fine
I think more than half of this thread is about syntactic ambiguity, regardless
of whether the ambiguity is real or not. For example, from [an earlier post of
this
thread](https://esdiscuss.org/topic/existential-operator-null-propagation-operator#content-44):
>But what
>IIRC the proposed syntax for computed properties was x?.[y],
Yes you’re right, sorry :/
IMO it still seems the syntax problem is the main reason why this proposal has
stalled. If not, what is the problem here? I’m curious why this proposal is not
even listed in stage 0 proposal list.
>Why is this needed? Why are people trying to get the property of an object
>which is null?
I will appreciate null propagation when a function receives an “option bag”
```js
function someFunction(options) {
if(options?.foo) {
doSomething();
};
}
someFunction();
someFunction({ foo: true
>From a technical point of view, using ![ instead of ?.[ may work only if you
>forbid a line terminator before the !
I tried this on [TS
Playground](http://www.typescriptlang.org/play/#src=var%20a%20%3D%20%7B%7D%3B%0D%0A%0D%0Aa!%5B3%5D%3B%0D%0Aa%0D%0A!%5B3%5D%3B)
and it interestingly changes be
I want to find a way to replace cancellation token in the current [stage 1
cancelable promise
proposal](https://github.com/tc39/proposal-cancelable-promises) with an
alternative way which does not require passing an additional parameter.
Here is a short representation of [my current
thought](h
s here separately to gain attention and discuss.
From: Marky Mark<mailto:m...@heyimmark.com>
Sent: Wednesday, October 19, 2016 11:20 AM
To: Kagami Rosylight<mailto:sascha...@outlook.com>;
es-discuss@mozilla.org<mailto:es-discuss@mozilla.org>
Subject: Re: Alternative way to achieve
Hi Bergi:
>You're not the only one who is unsatisfied with the current proposal :-) Also
>have a look at
Great! I’m yet to read them but I definitely will soon to discuss more.
>Promises are result values that can be passed to multiple consumers, and not
>every consumer should be allowed to ca
>So by default, promises must not be cancellable.
With some API change now the proposal allows this, similar to other token based
proposals:
```
// if you don’t want to allow other consumers cancel this call
// for security reasons or whatever, you can disallow it by
// creating chain explicitly
12 matches
Mail list logo