Re: Re: Class syntax enhancements

2016-09-26 Thread Kagami Rosylight
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

Re: Re: Existential Operator / Null Propagation Operator

2016-09-30 Thread Kagami Rosylight
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

Re: Re: Class syntax enhancements

2016-10-08 Thread Kagami Rosylight
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.

Re: Re: Existential Operator / Null Propagation Operator

2016-10-13 Thread Kagami Rosylight
Or `!.`, which unfortunately is now being used by TypeScript? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Existential Operator / Null Propagation Operator

2016-10-13 Thread Kagami Rosylight
>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

Re: Re: Existential Operator / Null Propagation Operator

2016-10-13 Thread Kagami Rosylight
>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.

Re: Re: Existential Operator / Null Propagation Operator

2016-10-13 Thread Kagami Rosylight
>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

Re: Re: Existential Operator / Null Propagation Operator

2016-10-13 Thread Kagami Rosylight
>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

Alternative way to achieve cancelable promise

2016-10-15 Thread Kagami Rosylight
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

RE: Alternative way to achieve cancelable promise

2016-10-18 Thread Kagami Rosylight
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

Re: Re: Alternative way to achieve cancelable promise

2016-10-20 Thread Kagami Rosylight
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

Re: Re: Alternative way to achieve cancelable promise

2017-05-07 Thread Kagami Rosylight
>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