Thanks, I wasn't aware of `do` expressions.
> Why introduce the function and cognitive overhead?
Not that it really matters (I was just giving an example) but your
alternative isn't achieving the same thing, which is to set a default to
width and height if and only if *neither* height or width
From: Olivier Lalonde (mailto:olalo...@gmail.com)
Date: 30 September 2016 at 07:21:10
> Given that JSON.parse doesn't necessarily return an object, would the
> noPrototype option would be ignored on e.g. `JSON.parse('"some string"')` or
> `JSON.parse('true')`?
The noPrototype option should set
On Thu, Sep 29, 2016 at 3:14 PM Michał Wadas wrote:
> Similar proposal is already here, do expressions.
>
Additionally...
>
> On 30 Sep 2016 12:06 a.m., "Olivier Lalonde" wrote:
>
>> I occasionally write IIFE to avoid introducing `let` variables,
Similar proposal is already here, do expressions.
On 30 Sep 2016 12:06 a.m., "Olivier Lalonde" wrote:
> I occasionally write IIFE to avoid introducing `let` variables, e.g.:
>
> ```
> const thumb = ({ width, height }) => {
> const { w, h } = (() => {
> // if either
I occasionally write IIFE to avoid introducing `let` variables, e.g.:
```
const thumb = ({ width, height }) => {
const { w, h } = (() => {
// if either width or height is set, don't set any default
if (Number.isInteger(width) || Number.isInteger(height)) {
return { w: width, h:
Given that JSON.parse doesn't necessarily return an object, would the
noPrototype option would be ignored on e.g. `JSON.parse('"some string"')`
or `JSON.parse('true')`?
On Wed, Sep 28, 2016 at 9:46 AM, 段垚 wrote:
> 在 2016/9/29 0:04, Michał Wadas 写道:
>
> Have you ever
ECMAScript claims JSON as a subset twice in
https://tc39.github.io/ecma262/#sec-json.parse , but (as has been
well-documented) that is not true because it JSON strings can contain
unescaped U+2028 LINE SEPARATOR and U+2029 PARAGRAPH SEPARATOR while
ECMAScript strings cannot. Mark Miller alludes to
On Thu, Sep 29, 2016 at 9:25 AM, Alexander Jones wrote:
> Maybe we should just make U+2028 and U+2029 valid in JS then? What other
> productions in JSON are invalid syntax in JS?
IIRC, Doug Crockford, possibly Mike Samuel, and I (and perhaps others)
advocated such a change to
On Wed, Sep 28, 2016 at 10:06 AM, Michał Wadas wrote:
> Idea: require implementations to stringify "" as "<\uscript>".
>
> Benefits: remove XSS vulnerability when injecting JSON as content of
>
On Thu, Sep 29, 2016 at 9:25 AM, Alexander Jones wrote:
> Maybe we should just make U+2028 and U+2029 valid in JS then? What other
> productions in JSON are invalid syntax in JS?
I don't think any other productions in JSON are invalid syntax in an
Expression context.
JSON places
Maybe we should just make U+2028 and U+2029 valid in JS then? What other
productions in JSON are invalid syntax in JS?
On Thursday, 29 September 2016, Mike Samuel wrote:
> On Thu, Sep 29, 2016 at 8:45 AM, Oriol Bugzilla
> > wrote:
On Thu, Sep 29, 2016 at 8:45 AM, Oriol Bugzilla
wrote:
>> ECMAScript, while highly used in web browsers, should really not care
>> about HTML constructs. That's where WHATWG and W3C come in. I suggest this
>> type of feature should come from one of those groups, not
> ECMAScript, while highly used in web browsers, should really not care about
> HTML constructs. That's where WHATWG and W3C come in. I suggest this type of
> feature should come from one of those groups, not ECMA.
That applies to escaping things like `` or `]]>`, and I agree. But as
Mike
On Thu, Sep 29, 2016 at 2:09 AM, Alexander Jones wrote:
> In XHTML, CDATA allows a 'more' verbatim spelling of text node content. But
> the end token has to be escaped, as discussed. Despite this escaping, the
> text node can contain arbitrary strings.
> In XHTML, you *can*
On Wed, 28 Sep 2016 19:06:31 +0200, Michał Wadas
wrote:
Idea: require implementations to stringify "" as
"<\uscript>".
Benefits: remove XSS vulnerability when injecting JSON as content of
In XHTML, CDATA allows a 'more' verbatim spelling of text node content. But
the end token has to be escaped, as discussed. Despite this escaping, the
text node can contain arbitrary strings.
In XHTML, you *can* achieve the same effect without CDATA, just by escaping
XML entities. Again, and
16 matches
Mail list logo