My understanding was that pretty much everyone in the room, at least those
who participated in the conversation, felt that refutable destructuring was
a mistake,
Can you elaborate, please? Why?
{ Kevin }
___
es-discuss mailing list
es-discuss
On Aug 15, 2013, at 9:27 PM, David Herman wrote:
This is *not* what I remember of the conversation, at all.
My understanding was that pretty much everyone in the room, at least those
who participated in the conversation, felt that refutable destructuring was a
mistake, but that we
that refutable
destructuring was a mistake, but that we couldn't really come to any
conclusions without Brendan and Andreas there, since the two of them had
championed refutable destructuring.
IOW, we don't have consensus about this issue.
Personally, I think there is all too much confusion over
And for the strict match one could introduce match(...) function which
already would throw providing exactly matching procedure first, and then
destructuring as a consequence.
Do you not think that it would be awkward to have the exact same pattern
syntax for these two cases (matching and
On Fri, Aug 16, 2013 at 11:26 AM, Kevin Smith zenpars...@gmail.com wrote:
And for the strict match one could introduce match(...) function which
already would throw providing exactly matching procedure first, and then
destructuring as a consequence.
Do you not think that it would be
Do you not think that it would be awkward to have the exact same pattern
syntax for these two cases (matching and destructuring), but with different
semantics?
Yes, I don't think so.
Hmmm... Let me rephrase. It would be awkward and confusing to have
divergent semantics for the same
On Fri, Aug 16, 2013 at 12:38 PM, Kevin Smith zenpars...@gmail.com wrote:
Do you not think that it would be awkward to have the exact same pattern
syntax for these two cases (matching and destructuring), but with different
semantics?
Yes, I don't think so.
Hmmm... Let me rephrase. It
On Aug 16, 2013, at 12:18 PM, Dmitry Soshnikov wrote:
On Fri, Aug 16, 2013 at 11:26 AM, Kevin Smith zenpars...@gmail.com wrote:
And for the strict match one could introduce match(...) function which
already would throw providing exactly matching procedure first, and then
destructuring as
On 8/16/2013 12:56 PM, Allen Wirfs-Brock wrote:
However, I think throwing is like to reveal bugs that might otherwise
be missed prior to deployment and as a code reader I would prefer to
encounter
let {x=undefined) = {};
which communicates much more clearly that there is an expectation that
Actually, I think it'd be fantastic to have an easy way to communicate required
parameters in an options object. It's a fairly common pattern; for example in
the S3 library knox that I maintain we require bucket, key, and secret, but
everything else has defaults.
. TypeScript is to ECMAScript as refutable
destructuring is to Axel's proposal.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
TypeScript exists, and
has gained such a following. TypeScript is to ECMAScript as refutable
destructuring is to Axel's proposal.
Again, this works except in a match construct, where failure to trigger
next-pattern attempt must be the default
was that pretty much everyone in the room, at least those who
participated in the conversation, felt that refutable destructuring was a
mistake, but that we couldn't really come to any conclusions without Brendan
and Andreas there, since the two of them had championed refutable destructuring.
IOW, we
On Aug 15, 2013, at 9:27 PM, David Herman dher...@mozilla.com wrote:
we couldn't really come to any conclusions without Brendan and Andreas there
My mistake, Brendan was there. It was only Andreas who wasn't there.
Dave
___
es-discuss mailing list
On Tuesday, August 13, 2013, Allen Wirfs-Brock wrote:
On Aug 13, 2013, at 2:31 PM, Brendan Eich wrote:
Andreas Rossberg wrote:
As I said in my reply, I'm totally fine with what you describe in that
mail. But correct me if I'm wrong, that_is_ refutable destructuring,
isn't it? All you
with a couple slight modification
that I had previously described in a private email exchange with you (which
I've copied below).
As I said in my reply, I'm totally fine with what you describe in that
mail. But correct me if I'm wrong, that _is_ refutable destructuring,
isn't it? All you seem
Andreas Rossberg wrote:
As I said in my reply, I'm totally fine with what you describe in that
mail. But correct me if I'm wrong, that_is_ refutable destructuring,
isn't it? All you seem to drop is the optional irrefutable part (the
'?' feature). That's why I am quite confused about Brendan's
On Aug 13, 2013, at 2:31 PM, Brendan Eich wrote:
Andreas Rossberg wrote:
As I said in my reply, I'm totally fine with what you describe in that
mail. But correct me if I'm wrong, that_is_ refutable destructuring,
isn't it? All you seem to drop is the optional irrefutable part
Allen Wirfs-Brock wrote:
On Aug 13, 2013, at 2:31 PM, Brendan Eich wrote:
Andreas Rossberg wrote:
As I said in my reply, I'm totally fine with what you describe in that
mail. But correct me if I'm wrong, that_is_ refutable destructuring,
isn't it? All you seem to drop is the optional
On 10 August 2013 22:15, Brendan Eich bren...@mozilla.com wrote:
Pattern matching is more precise and flexible, and that's why we considered
changing destructuring (which uses the pattern subgrammar) to refutable from
irrefutable. Even now with destructuring irrefutable, patterns in catch
On Aug 12, 2013, at 2:22 AM, Andreas Rossberg wrote:
On 10 August 2013 22:15, Brendan Eich bren...@mozilla.com wrote:
Pattern matching is more precise and flexible, and that's why we considered
changing destructuring (which uses the pattern subgrammar) to refutable from
irrefutable. Even now
It looks to me like there are people who want a sort of ducktypeof operator.
arg1 ducktypeof MyClass
Which would return true if the shape of arg1 where the same as MyClass. If
I wanted to write as a refutable pattern I could end up with a large block
that may be repeated in several class
ES4 had this as like (at one point is like):
(arg1 like MyClass)
How deep this goes is one design decision; there are lots of others.
Pattern matching is more precise and flexible, and that's why we
considered changing destructuring (which uses the pattern subgrammar) to
refutable from
On Fri, Aug 9, 2013 at 11:52 PM, Brendan Eich bren...@mozilla.com wrote:
Rick Waldron wrote:
My argument was specifically about the current meaning of the ascii
exclamation ! and that assigning it an additional context-based meaning
that's quite the opposite of the current unary operator
AFAICT, there is no current consensus on whether destructuring assignment is
refutable by default or not:
https://github.com/rwldrn/tc39-notes/blob/master/es6/2013-07/july-23.md#44-consider-deferring-es6-refutable-matching
Could we make destructuring assignment fail soft and introduce a marker
Woah. I was sad about the loss of refutable destructuring, i.e. I would rather
have had it by default, but this idea is a pretty brilliant way to make
lemonade out of lemons. I would *love* a way to declaratively specify required
parameters.
___
es
On Fri, Aug 9, 2013 at 5:54 PM, Axel Rauschmayer a...@rauschma.de wrote:
AFAICT, there is no current consensus on whether destructuring assignment
is refutable by default or not:
While I agree this is interesting and should be explored further, I reject
the proposal to add more meaning to the ! character. Given this proposal,
! would sometimes mean not or negate (as in it's current form) and
sometimes mean a required thing. Meanwhile, refute is a synonym for
On 8/9/2013 3:36 PM, Axel Rauschmayer wrote:
let { +a: foo, b: bar } = { a: 1 }; // foo = 1, b = undefined
let { +a: foo, b: bar } = { }; // exception
function bla(+mandatoryArg, optionalArg1, optionalArg2 = 123) {
...
}
I presume these would also be valid, and do
On Aug 9, 2013, at 3:32 PM, Rick Waldron waldron.r...@gmail.com wrote:
On Fri, Aug 9, 2013 at 5:54 PM, Axel Rauschmayer a...@rauschma.de wrote:
AFAICT, there is no current consensus on whether destructuring assignment is
refutable by default or not:
On Aug 9, 2013, at 2:58 PM, Domenic Denicola wrote:
Woah. I was sad about the loss of refutable destructuring, i.e. I would
rather have had it by default, but this idea is a pretty brilliant way to
make lemonade out of lemons. I would *love* a way to declaratively specify
required
On Fri, Aug 9, 2013 at 6:40 PM, Brendan Eich bren...@mozilla.com wrote:
On Aug 9, 2013, at 3:32 PM, Rick Waldron waldron.r...@gmail.com wrote:
On Fri, Aug 9, 2013 at 5:54 PM, Axel Rauschmayer a...@rauschma.de wrote:
AFAICT, there is no current consensus on whether destructuring assignment
On 8/9/2013 4:03 PM, Allen Wirfs-Brock wrote:
const MUST = () = {throw TypeError(Missing required parameter};
function foo (a=MUST(), b, c) {...}
But that doesn't work for:
```js
function foo({ a } = { a: MUST() }){}
foo({}); // doesn't throw
function bar({ +a }){}
bar({}); // would throw
On Aug 9, 2013, at 4:21 PM, Brandon Benvie wrote:
On 8/9/2013 4:03 PM, Allen Wirfs-Brock wrote:
const MUST = () = {throw TypeError(Missing required parameter};
function foo (a=MUST(), b, c) {...}
But that doesn't work for:
```js
function foo({ a } = { a: MUST() }){}
this would
On Aug 9, 2013, at 5:37 PM, Allen Wirfs-Brock wrote:
On Aug 9, 2013, at 4:21 PM, Brandon Benvie wrote:
On 8/9/2013 4:03 PM, Allen Wirfs-Brock wrote:
const MUST = () = {throw TypeError(Missing required parameter};
function foo (a=MUST(), b, c) {...}
But that doesn't work for:
On 8/9/2013 5:45 PM, Allen Wirfs-Brock wrote:
and if we make U+2639 a special token that evaluated to throw TypeError we
could say
function foo( {a=☹ }) {}
This would be awesome.
___
es-discuss mailing list
es-discuss@mozilla.org
Rick Waldron wrote:
My argument was specifically about the current meaning of the ascii
exclamation ! and that assigning it an additional context-based
meaning that's quite the opposite of the current unary operator meaning,
Ok, and I'm with you (recall Mark M. wants ! as
37 matches
Mail list logo
