I must say throwing here, instead of relying on math dictated operators
precedence looks really bad.
It's very surprising to those well experienced with the language, and
totally inconsistent with how operators worked so far (there is no previous
case where one will throw for similar reason).
Als
It's quite simple (as has already been stated): some people expect `-x **
y` to be `-(x ** y)`. Some expect it to be `(-x) ** y`.
The early SyntaxError ensures that nobody is confused - programmers will
immediately add parens to disambiguate.
Avoiding a potential footgun for the next 50 years, at
There are many other cases when with no parens involved, people have
different expectations on the outcome.
If expression looks ambigous the actual result always depends on operators
precedence, it's how language worked for years, and I don't remember any big
problems due to that.
Jordan Harband
I'll point out that encoding and evaluating JSON literally can easily
become a potential security issue, anyways (consider if a user can encode
`-->` in the relevant data). But you might have a point if you
consider JSONP.
On Sun, Oct 16, 2016, 22:08 Richard Gibson wrote:
> Allow me to clarify:
Okay. I stand corrected (it was in fact `["__proto__"]` that actually
evaluates to the property).
-
Isiah Meadows
m...@isiahmeadows.com
On Tue, Oct 18, 2016 at 9:58 AM, Raul-Sebastian Mihăilă <
raul.miha...@gmail.com> wrote:
> Note that `["__proto__"]` is different from `__proto__`, while
>
Note that `["__proto__"]` is different from `__proto__`, while
`"__proto__"` is the same as `__proto__`.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On Tue, Oct 18, 2016 at 8:57 AM, Isiah Meadows
wrote:
> I'll point out that encoding and evaluating JSON literally can easily
> become a potential security issue, anyways (consider if a user can encode
> `-->` in the relevant data). But you might have a point if you
> consider JSONP.
>
This feel
If tc39 wanted to implement it one way or the other, they would indeed
use precedence. The problem is that the precedence of unary '-' vs
binary '**' is ambiguous *between different people's heads* -- not just
a little, but a lot. So whichever precedence you pick, some people will
be very surpr
At the moment, when we call a synchronous function that runs some kind of
operation, there are two obvious ways of returning whether there has been an
error: returning a boolean or throwing an error.
Returning a boolean to show whether the operation worked is simple, but doesn't
give any indica
Not sure if I'm missing something, but wouldn't it be trivial to code that
constructor in JS?
```js
class Result {
constructor (type, value=true) {
this[type] = value;
}
}
function add(data) {
if (data !== Object(data)) {
return new Result('error', new Error('The data is not an obj
> Not sure if I'm missing something, but wouldn't it be trivial to code that
> constructor in JS?
Yes it would be trivial, but my design I came up with was an example. The point
I wanted to get across was to have some sort of standard practice for error
handling using `return` rather than `thro
Inline.
On Tue, Oct 18, 2016, 12:01 Richard Gibson wrote:
> On Tue, Oct 18, 2016 at 8:57 AM, Isiah Meadows
> wrote:
>
> I'll point out that encoding and evaluating JSON literally can easily
> become a potential security issue, anyways (consider if a user can encode
> `-->` in the relevant data)
I would also like to point out that V8 is one of few that don't optimize
`try-catch`, and both Chakra and SpiderMonkey do optimize them IIRC (the
latter has trouble optimizing functions that throw, though).
On Tue, Oct 18, 2016, 15:29 Josh Tumath wrote:
> > Not sure if I'm missing something, but
try/catch is often misunderstood as people think that they MUST catch
errors as close as possible to the point where they may be thrown.
Good EH practice is exactly the opposite: place a few try/catch in
strategic places where you can report the error and recover from it; and
let errors bubble up
I agree with this: if a result may fail normally, I would just return a
sentinel value like `undefined` (I usually avoid `null`). If it's truly
exceptional, don't catch it except to log it/etc.
On Tue, Oct 18, 2016, 17:49 Bruno Jouhier wrote:
> try/catch is often misunderstood as people think th
The issue with that, though, is returning `undefined` is really no different to
returning `null` in a sense. Null is considered bad because errors can crop up
from not handling null as a return value from a function. Using `undefined`
does not solve the problem. It also isn’t able to explain the
I must admit that I do like this approach, however I'm not too familiar
with the proposed spec to definitively comment on this. Have you tried
proposing this in the
https://github.com/tc39/proposal-cancelable-promises repository?
That may be a better avenue for your suggestions.
On Sat, Oct 15, 20
I thought I’d raise a discussion on just what exactly iterators are, a
simple view might be that they’re just a sequence of values which can be
gotten using .next(). However this is simplified because iterators .next
can actually do three things:
1.
They can yield a value
2.
They can
Thank you for your interest in my proposal. :D
I also thought so and I posted [an older version of my proposal on
June](https://github.com/tc39/proposal-cancelable-promises/issues/22) there. I
got this answer:
>This is a separate proposal, and not an issue with the proposal being
>developed in
19 matches
Mail list logo