+1
Good step toward (`JS` <= [`Scala`](
https://www.scala-lang.org/documentation/) ) unification. ( [flatMap](
https://www.scala-lang.org/api/current/scala/collection/TraversableLike.html#flatMap[B](f:A=>scala.collection.GenTraversableOnce[B]):Traversable[B])
, [flatten](
https://www.scala-lang.or
It would be nice to have `error.prettyStack` and
`Execution.getPrettyStack()` / `Error.capturePrettyStackTrace(..)` to
capture same nice stack trace as `console.error(..)` does.
Generally problem with `error.stack` is that is is plain-text value, and it
does not take into account source mapping. A
previous discussion (FYI)
[operator-overloading-proposal](/topic/operator-overloading-proposal)
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Actually initial discussion which "inspires" me on this thoughts was in
[cancellation-tokens-related](/topic/cancel-promise-pattern-no-cancellable-promises)
topic. So here I didn't mean that it is impossible to implement that kind
of functionality on "home made" promises. I mean that it would be go
Yes, it's good note, that it can be "too public" and may be some one would
like to prevent external "intrusion" into it's "private state", but it can
be easily solved by the means of a wrappers, that wraps some private
``target`` and delegate to it only "safe calls", that will not
interrupt-it/canc
Introduction of promise.return() and promise.throw() similar to
generator.return() and generator.throw() can be helpful
Assuming analogy in tuples ([``function*``](https://
developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/
Statements/function*), [``yield``](https://developer.
mozilla.org/
Check on practice hove [bluebirdjs-cancellation](
http://bluebirdjs.com/docs/api/cancellation.html) works and find out that
[promise-executor](
https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Global_Objects/Promise#Parameters).``onCancel``
callback get executed before finally blocks
> Um... This isn't much different than Bluebird's
`Promise.prototype.cancel`,
> admittedly the least optimal of all these so far.
Yes, very similar, in that it is propagated upward on "async-stacktrace",
and can be actually handled in [promise-executor](
https://developer.mozilla.org/en/docs/Web/J
In general I thing it would be good to have something like
[``java``(``Thread.interrupt()``)](
https://docs.oracle.com/javase/7/docs/api/java/lang/Thread.html#interrupt()),
assuming that "Thread" here can be "async stacktrace of promises", and
interrupt notification should be just forwarded to top
As I've mentioned in initial post
> this idea "isn't new", something very similar I saw in
[[async-do]](/topic/support-syntax#content-5) comment
So answer yes - it quite the same idea. However as for me ``do`` part is
quite optional and can be omitted without any lost (in this construct).
Meaning
For me ``.?.`` looks more strict. With variations: ``a.?.b.?.c``,
``a.?(args)``, ``a.?[key]``.
Since I would rather look on it like on something similar to [C# extension
method](https://msdn.microsoft.com/en-us//library/bb383977.aspx) (or [Scala
implicit method](
http://docs.scala-lang.org/overview
It would be nice to have something like "destructed with" -
with(point.{x,y}){...}
Well known issue with ``with`` is that it may provide some "noise" (some
unwonted names) into scope, plus code inside ``with`` can be poorly
optimize, since names can not be resolved statically inside it body.
Whil
I looks like it would be nice to have ``async``-block which might be alias
to ``async``-lambda immediate invocation, so that:
```js
var promise = async { /*some statements with await*/ };
```
<==>
```js
var promise = (async () => { /*some statements with await*/ }) ();
```
and
```js
var promise
By the way it looks very similar to [s-ctypes/StructType](
https://developer.mozilla.org/en-US/docs/Mozilla/js-ctypes/js-ctypes_reference/StructType#Describing_fields)
Although it designed for interoperability with native code (not for code
performance improvement, or better code readability), it
Speaking about well-known symbols for operators, I would rather propose
more complex but less ambiguous solution. I think better approach is to
provide some advanced mapping object, that implements following mapping:
(operatorName, ...argumentsTypes) <==> operatorSymbol <==>
OperatorDescriptor(ope
I think it would be also nice to have some "low level API" that would allow
to provide some interceptor object, which will trap all operators
invocations in some block of code. (at least for cases when both/some
arguments of operation are not primitives). Then if this particular
interceptor can't h
x27;s a good thing, too, because adding a new Proxy trap is a last
>> resort. Just from a conceptual standpoint, the less complicated
>> objects are, the better; just because there are 14 *fundamental*
>> operations on objects doesn't mean we're eager to add more. But
&
eptual standpoint, the less complicated
> objects are, the better; just because there are 14 *fundamental*
> operations on objects doesn't mean we're eager to add more. But
> there's also an inherent compatibility issue. Whenever you add a new
> trap, the deal is, all exis
It would be nice to "bring sense" to expressions like "obj(a1, ... , aN) =
val". (like "obj(x) = y")
In Scala langue it defined in pretty clear and simple way:
"obj(a1, ... , aN)" <==> "obj.apply(a1, ... , aN)"
"obj(a1, ... , an) = *val*" <==> "obj.update(a1, ... , aN, *val*)"
Of course t
19 matches
Mail list logo
