Re: Using destructuring for function arguments
On Sat, May 31, 2014 at 1:41 PM, Brendan Eich wrote: > Matthew Robb wrote: > >> Seems like any identifiers in the arguments should always be defined in >> scope before ever considering what they will be assigned. >> > > Right, and they are in scope no matter what. > > Seems to me that an implementation bug (can't have parameter default value > for destructuring formal) is the only problem brought to light in this > thread. Anyone see anything else amiss? > > No, seems it's the only problem. Also, just to add: esprima parser also has this bug yet (can't have param default value with patterns). Dmitry ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Using destructuring for function arguments
Or, for more readable code:
function setCookie(name, value, options = {}) {
let {
secure = false,
path = "",
domain = "",
expires = whenever()
} = options;
// Do stuff
}
Kevin
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Using destructuring for function arguments
In addition to what Allen said, you could also do something like this:
function setCookie(name, value, { secure, path, domain, expires } =
cookieDefaults) { }
where `cookieDefaults` is defined elsewhere.
Or you could do something like:
function setCookie(name, value, { secure = false, path = ".", domain =
"", expires = now() } = {}) { }
where you are specifying default initializers within the destructuring
pattern.
Kevin
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Using destructuring for function arguments
On Sat, May 31, 2014 at 1:59 PM, Nicholas C. Zakas
wrote:
> 1. Who is right about assigning a default value to a destructured parameter,
> Firefox or Traceur?
Traceur is right.
> 2. Is the behavior of not having any bindings for destructured parameter
> properties correct? And if so, is it desirable?
I think you're mistaken about this. What happens is that
function setCookie(name, value, { secure, path, domain, expires }) {
console.log(secure);
// ...
}
behaves like
function setCookie(name, value, options) {
var { secure, path, domain, expires } = options;
console.log(secure);
// ...
}
and the error is in trying to unpack options, which is undefined, not
in later trying to use the variables.
-j
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Using destructuring for function arguments
On May 31, 2014, at 8:59 PM, Nicholas C. Zakas
wrote:
> I've been playing around with using destructuring as function arguments and
> have come across some odd behaviors that I'm not sure are intentional (or
> perhaps, not to spec).
Argument binding initialization takes place as part of
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-functiondeclarationinstantiation
The actual initialization takes place in steps 24-25, essentially treating the
entire parameter list as an array-like restructuring
Note that there has been significant tweaks to this section in each of the 3
latest spec. drafts. You favorite implementation may not match the current
spec. text.
> For context, consider the following function:
>
> ```
> function setCookie(name, value, { secure, path, domain, expires }) {
>console.log(secure);
>// ...
> }
>
> // called as
> setCookie("type", "js", {
>secure: true
> });
> ```
>
> What happens here:
> * `secure === true`
> * `path === undefined`
> * `domain === undefined`
> * `expires === undefined`
>
> I'd say all of that behavior is as expected. However, if I omit the third
> argument completely, things get a bit strange:
>
> ```
> setCookie("type", "js"); // throws error at console.log
> ```
>
correct, this should throw a TypeError exception because desctructuring
patterns (in any context) require an object value to restructure. Since you
did not pass a third argument there is no object to restructure into {secure,
path, domain, expires}
> What happens here is that none of `secure`, `path`, `domain`, `expires` are
> defined. I can use `typeof` on them to protect against this, but then I end
> up with some lousy looking code:
not really, the thrown exception while processing the arguments should
terminate the function and you should never start executing the function body
>
> ```
> function setCookie(name, value, { secure, path, domain, expires }) {
>
>if (typeof secure !== "undefined") {
>// use it
>}
>
>if (typeof path !== "undefined") {
>// use it
>}
>
>if (typeof domain !== "undefined") {
>// use it
>}
>
>if (typeof expires !== "undefined") {
>// use it
>}
>
>// ...
> }
> ```
>
> My first thought was that this behavior made sense, since no destructuring
> can happen on undefined. However, the workaround for dealing with that
> behavior seems a bit heavy-handed.
>
> I thought perhaps I could assign a default value, and that would solve the
> problem:
>
> ```
> function setCookie(name, value, { secure, path, domain, expires } = {}) {
>console.log(secure);
>// …
yes the above is exactly what you are expected to do. Or you could include
some defaults in the default object:
{secure, path, domain, expires } = {secure: false}
> }
> ```
>
> Unfortunately, that resulted in a syntax error in Firefox. Traceur seems to
> have no problem with it.
that sounds like a Firefox bug
>
> So I really have two questions:
>
> 1. Who is right about assigning a default value to a destructured parameter,
> Firefox or Traceur?
Traceur
> 2. Is the behavior of not having any bindings for destructured parameter
> properties correct? And if so, is it desirable?
no, it is supposed to throw as discussed above.
Allen
>
> Thanks.
>
> --
> ___
> Nicholas C. Zakas
> http://www.nczonline.net
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Using destructuring for function arguments
Matthew Robb wrote: Seems like any identifiers in the arguments should always be defined in scope before ever considering what they will be assigned. Right, and they are in scope no matter what. Seems to me that an implementation bug (can't have parameter default value for destructuring formal) is the only problem brought to light in this thread. Anyone see anything else amiss? /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Using destructuring for function arguments
Nicholas C. Zakas wrote:
```
function setCookie(name, value, { secure, path, domain, expires } = {}) {
console.log(secure);
// ...
}
```
Unfortunately, that resulted in a syntax error in Firefox.
Could you please file a bug against SpiderMonkey? Thanks,
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Using destructuring for function arguments
On Sat, May 31, 2014 at 11:59 AM, Nicholas C. Zakas <
standa...@nczconsulting.com> wrote:
> I've been playing around with using destructuring as function arguments
> and have come across some odd behaviors that I'm not sure are intentional
> (or perhaps, not to spec). For context, consider the following function:
>
> ```
> function setCookie(name, value, { secure, path, domain, expires }) {
> console.log(secure);
> // ...
> }
>
> // called as
> setCookie("type", "js", {
> secure: true
> });
> ```
>
> What happens here:
> * `secure === true`
> * `path === undefined`
> * `domain === undefined`
> * `expires === undefined`
>
> I'd say all of that behavior is as expected. However, if I omit the third
> argument completely, things get a bit strange:
>
> ```
> setCookie("type", "js"); // throws error at console.log
> ```
>
> What happens here is that none of `secure`, `path`, `domain`, `expires`
> are defined. I can use `typeof` on them to protect against this, but then I
> end up with some lousy looking code:
>
> ```
> function setCookie(name, value, { secure, path, domain, expires }) {
>
> if (typeof secure !== "undefined") {
> // use it
> }
>
> if (typeof path !== "undefined") {
> // use it
> }
>
> if (typeof domain !== "undefined") {
> // use it
> }
>
> if (typeof expires !== "undefined") {
> // use it
> }
>
> // ...
> }
> ```
>
>
Strange, it seems should fail at trying to start destructuring process:
when ToObject coercion fails with the `undefined` value set to the value of
the parameter.
> My first thought was that this behavior made sense, since no destructuring
> can happen on undefined. However, the workaround for dealing with that
> behavior seems a bit heavy-handed.
>
> I thought perhaps I could assign a default value, and that would solve the
> problem:
>
> ```
> function setCookie(name, value, { secure, path, domain, expires } = {}) {
> console.log(secure);
> // ...
> }
> ```
>
> Unfortunately, that resulted in a syntax error in Firefox. Traceur seems
> to have no problem with it.
>
> So I really have two questions:
>
> 1. Who is right about assigning a default value to a destructured
> parameter, Firefox or Traceur?
>
Well, the the `FormalParameter` is the `BindingElement`, and the later may
be the `BindingPattern Initializer`, where the `Initializer` is your
default value. From which chain Traceur is correct.
> 2. Is the behavior of not having any bindings for destructured parameter
> properties correct? And if so, is it desirable?
>
Where do you test this? It seems it should fail at destructuring, and not
set any binding pattern properties in this case.
I.e.
```
setCookie('type', 'js'); // throws right away, since no ToObject coercion
is made
setCookie('type', 'js', {}); // sets all binding props to undefined
```
With the default value of the pattern, the first call sets all binding
props to `undefined` as well.
Dmitry
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Using destructuring for function arguments
Seems like any identifiers in the arguments should always be defined in
scope before ever considering what they will be assigned.
On May 31, 2014 11:59 AM, "Nicholas C. Zakas"
wrote:
> I've been playing around with using destructuring as function arguments
> and have come across some odd behaviors that I'm not sure are intentional
> (or perhaps, not to spec). For context, consider the following function:
>
> ```
> function setCookie(name, value, { secure, path, domain, expires }) {
> console.log(secure);
> // ...
> }
>
> // called as
> setCookie("type", "js", {
> secure: true
> });
> ```
>
> What happens here:
> * `secure === true`
> * `path === undefined`
> * `domain === undefined`
> * `expires === undefined`
>
> I'd say all of that behavior is as expected. However, if I omit the third
> argument completely, things get a bit strange:
>
> ```
> setCookie("type", "js"); // throws error at console.log
> ```
>
> What happens here is that none of `secure`, `path`, `domain`, `expires`
> are defined. I can use `typeof` on them to protect against this, but then I
> end up with some lousy looking code:
>
> ```
> function setCookie(name, value, { secure, path, domain, expires }) {
>
> if (typeof secure !== "undefined") {
> // use it
> }
>
> if (typeof path !== "undefined") {
> // use it
> }
>
> if (typeof domain !== "undefined") {
> // use it
> }
>
> if (typeof expires !== "undefined") {
> // use it
> }
>
> // ...
> }
> ```
>
> My first thought was that this behavior made sense, since no destructuring
> can happen on undefined. However, the workaround for dealing with that
> behavior seems a bit heavy-handed.
>
> I thought perhaps I could assign a default value, and that would solve the
> problem:
>
> ```
> function setCookie(name, value, { secure, path, domain, expires } = {}) {
> console.log(secure);
> // ...
> }
> ```
>
> Unfortunately, that resulted in a syntax error in Firefox. Traceur seems
> to have no problem with it.
>
> So I really have two questions:
>
> 1. Who is right about assigning a default value to a destructured
> parameter, Firefox or Traceur?
> 2. Is the behavior of not having any bindings for destructured parameter
> properties correct? And if so, is it desirable?
>
> Thanks.
>
> --
> ___
> Nicholas C. Zakas
> http://www.nczonline.net
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Using destructuring for function arguments
I've been playing around with using destructuring as function arguments
and have come across some odd behaviors that I'm not sure are
intentional (or perhaps, not to spec). For context, consider the
following function:
```
function setCookie(name, value, { secure, path, domain, expires }) {
console.log(secure);
// ...
}
// called as
setCookie("type", "js", {
secure: true
});
```
What happens here:
* `secure === true`
* `path === undefined`
* `domain === undefined`
* `expires === undefined`
I'd say all of that behavior is as expected. However, if I omit the
third argument completely, things get a bit strange:
```
setCookie("type", "js"); // throws error at console.log
```
What happens here is that none of `secure`, `path`, `domain`, `expires`
are defined. I can use `typeof` on them to protect against this, but
then I end up with some lousy looking code:
```
function setCookie(name, value, { secure, path, domain, expires }) {
if (typeof secure !== "undefined") {
// use it
}
if (typeof path !== "undefined") {
// use it
}
if (typeof domain !== "undefined") {
// use it
}
if (typeof expires !== "undefined") {
// use it
}
// ...
}
```
My first thought was that this behavior made sense, since no
destructuring can happen on undefined. However, the workaround for
dealing with that behavior seems a bit heavy-handed.
I thought perhaps I could assign a default value, and that would solve
the problem:
```
function setCookie(name, value, { secure, path, domain, expires } = {}) {
console.log(secure);
// ...
}
```
Unfortunately, that resulted in a syntax error in Firefox. Traceur seems
to have no problem with it.
So I really have two questions:
1. Who is right about assigning a default value to a destructured
parameter, Firefox or Traceur?
2. Is the behavior of not having any bindings for destructured parameter
properties correct? And if so, is it desirable?
Thanks.
--
___
Nicholas C. Zakas
http://www.nczonline.net
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Proposal: The Conditional Fail and Recover Operators; or: a more generic Existential Operator
At JSConf there was a talk about using macros to experiment with new language features. The library mentioned is sweet.js (http://sweetjs.org/). Maybe you could implement it as a macro for developers to play around? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
