Brandon Benvie wrote:
On 8/16/2013 2:08 PM, Domenic Denicola wrote:
Actually, I think it'd be fantastic to have an easy way to
communicate required parameters in an options object.
I agree and this is why I was a fan of Axel's +/! "this is required"
prefix.
Having such syntax available woul
On 8/16/2013 2:08 PM, Domenic Denicola wrote:
Actually, I think it'd be fantastic to have an easy way to communicate required
parameters in an options object.
I agree and this is why I was a fan of Axel's +/! "this is required" prefix.
One of the reason's JS is so popular is because hard fail
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.
___
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
On Aug 16, 2013, at 12:18 PM, Dmitry Soshnikov wrote:
> On Fri, Aug 16, 2013 at 11:26 AM, Kevin Smith 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.
On Fri, Aug 16, 2013 at 12:38 PM, Kevin Smith 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
> 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 s
On Fri, Aug 16, 2013 at 11:26 AM, Kevin Smith 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 awkward to have
>
>
> 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
On Friday, August 16, 2013, Allen Wirfs-Brock wrote:
>
> 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
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 co
>
> 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:
> 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
es-discuss@mozilla.o
On Aug 14, 2013, at 9:54 AM, Dmitry Soshnikov
wrote:
> throws
>
> to bind to undefined you would say:
>
> var {p=undefined} = {};
>
>
> OK, so it's turned out to be refutable nevertheless.
This is *not* what I remember of the conversation, at all.
My understanding was that pretty much ever
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
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 irrefuta
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 (the
>>
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 st
On 12 August 2013 18:52, Allen Wirfs-Brock wrote:
> On Aug 12, 2013, at 2:22 AM, Andreas Rossberg wrote:
>> On 10 August 2013 22:15, Brendan Eich wrote:
>>> Pattern matching is more precise and flexible, and that's why we considered
>>> changing destructuring (which uses the pattern subgrammar) t
On Aug 12, 2013, at 2:22 AM, Andreas Rossberg wrote:
> On 10 August 2013 22:15, Brendan Eich 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 destruc
On 10 August 2013 22:15, Brendan Eich 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
> clauses, match state
On Fri, Aug 9, 2013 at 11:52 PM, Brendan Eich 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 meaning,
>>
>
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 ir
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 methods.
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 restricted-producti
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
https://mail.moz
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
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() }){}
th
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 Fri, Aug 9, 2013 at 6:40 PM, Brendan Eich wrote:
> On Aug 9, 2013, at 3:32 PM, Rick Waldron wrote:
>
> On Fri, Aug 9, 2013 at 5:54 PM, Axel Rauschmayer wrote:
>
>> AFAICT, there is no current consensus on whether destructuring assignment
>> is refutable by default or not:
>>
>> https://githu
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 para
On Aug 9, 2013, at 3:32 PM, Rick Waldron wrote:
> On Fri, Aug 9, 2013 at 5:54 PM, Axel Rauschmayer wrote:
>> 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
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 the
> 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 syno
On Fri, Aug 9, 2013 at 5:54 PM, Axel Rauschmayer wrote:
> 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
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-di
36 matches
Mail list logo