Implement Debugger.Object.prototype.parameterNames for destructured parameters

NEW
Unassigned

Status

()

Core
JavaScript Engine
P3
normal
4 years ago
4 years ago

People

(Reporter: benvie, Unassigned)

Tracking

(Blocks: 1 bug)

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

4 years ago
Right now if you get the parameterNames for `(function([a], {b}){})` you get `[undefined, undefined]`. The spec states that this should return a mapping of the destructuring as objects/arrays depending on pattern type, so the above should return `[["a"], {b: "b"}]`. This would be really useful to have, so that we can display the parameters to all functions.
(Reporter)

Updated

4 years ago
Component: Developer Tools: Debugger → JavaScript Engine
Product: Firefox → Core
(Reporter)

Comment 1

4 years ago
Additionally, the representation of destructured parameters should support rest element in array patterns. It needs to support something like:

> function foo([, ...bar]) {}

This doesn't currently work in SpiderMonkey, but it will eventually need to because it's in the ES6 spec (bug 905359).
(Reporter)

Comment 2

4 years ago
ALSO we somehow need to support default values for destructured parameters, as in:

> function foo({ a = 10 }) {}

This further complicates the structure needed to fully represent what parameters can do.

Updated

4 years ago
Blocks: 948489

Comment 3

4 years ago
Yeah, this is a very interesting area. I'd be interested to see design proposals.
(Reporter)

Comment 4

4 years ago
How about something like the following examples:

function objectPattern({ x: _x = 20, y }) {}
[
  {
    x: {
      binding: "_x",
      default: "20"
    },
    y: {
      binding: "y",
      default: null
    }
  }
]


function arrayPattern([bar, , lol = bar * 10, ...rest]) {}
[
  [
    {
      binding: "bar",
      default: null
    },
    null,
    {
      binding: "lol",
      default: "bar * 10"
    },
    {
      binding: "rest"
      rest: true
    }
  ]
]

function restElemenet(a, b, ...rest) {}
[
  "a",
  "b",
  {
    binding: "rest",
    rest: true
  }
]

function combined({ x: _x = 20, y }, [bar, , lol = bar * 10, ...r] = [], ...rest) {}
[
  {
    x: {
      binding: "_x",
      default: "20"
    },
    y: {
      binding: "y",
      default: null
    }
  },
  [
    {
      binding: "bar",
      default: null
    },
    null,
    {
      binding: "lol",
      default: "bar * 10"
    },
    {
      binding: "r"
      rest: true
    }
  ],
  {
    binding: "rest",
    rest: true
  }
]
(In reply to Brandon Benvie [:benvie] from comment #4)
> How about something like the following examples:

This looks pretty good to me. Couple comments below.

> 
> function objectPattern({ x: _x = 20, y }) {}
> [
>   {
>     x: {
>       binding: "_x",
>       default: "20"
>     },
>     y: {
>       binding: "y",
>       default: null
>     }
>   }
> ]

Because |y| will be |undefined| when the passed in object is missing a |y| property, I think either y's default should be |undefined| or the whole default property should be missing. I'm leaning towards the default property be missing for |y| so that we can differentiate between |y=undefined| and plain old |y|.

> 
> 
> function arrayPattern([bar, , lol = bar * 10, ...rest]) {}
> [
>   [
>     {
>       binding: "bar",
>       default: null
>     },
>     null,
>     {
>       binding: "lol",
>       default: "bar * 10"
>     },
>     {
>       binding: "rest"
>       rest: true
>     }
>   ]
> ]

Again, I'm thinking there shouldn't be a |default| property when there isn't an explicit default.

> 
> function restElemenet(a, b, ...rest) {}
> [
>   "a",
>   "b",
>   {
>     binding: "rest",
>     rest: true
>   }
> ]
> 
> function combined({ x: _x = 20, y }, [bar, , lol = bar * 10, ...r] = [],
> ...rest) {}
> [
>   {
>     x: {
>       binding: "_x",
>       default: "20"
>     },
>     y: {
>       binding: "y",
>       default: null
>     }
>   },
>   [
>     {
>       binding: "bar",
>       default: null
>     },
>     null,
>     {
>       binding: "lol",
>       default: "bar * 10"
>     },
>     {
>       binding: "r"
>       rest: true
>     }
>   ],
>   {
>     binding: "rest",
>     rest: true
>   }
> ]

This is missing the default empty array. How would you represent that?
(Reporter)

Comment 6

4 years ago
(In reply to Nick Fitzgerald [:fitzgen] from comment #5)
> > function objectPattern({ x: _x = 20, y }) {}
> > [
> >   {
> >     x: {
> >       binding: "_x",
> >       default: "20"
> >     },
> >     y: {
> >       binding: "y",
> >       default: null
> >     }
> >   }
> > ]
> 
> Because |y| will be |undefined| when the passed in object is missing a |y|
> property, I think either y's default should be |undefined| or the whole
> default property should be missing. I'm leaning towards the default property
> be missing for |y| so that we can differentiate between |y=undefined| and
> plain old |y|.


This is a good idea. The property should be missing though, since `function f(x){}` and `function f(x = undefined) {}` are observably different (the first has a `length` of 1, the second 0. Since this actually makes a difference we should be able to indicate it via the API.

> > function restElemenet(a, b, ...rest) {}
> > [
> >   "a",
> >   "b",
> >   {
> >     binding: "rest",
> >     rest: true
> >   }
> > ]
> > 
> > function combined({ x: _x = 20, y }, [bar, , lol = bar * 10, ...r] = [],
> > ...rest) {}
> > [
> >   {
> >     x: {
> >       binding: "_x",
> >       default: "20"
> >     },
> >     y: {
> >       binding: "y",
> >       default: null
> >     }
> >   },
> >   [
> >     {
> >       binding: "bar",
> >       default: null
> >     },
> >     null,
> >     {
> >       binding: "lol",
> >       default: "bar * 10"
> >     },
> >     {
> >       binding: "r"
> >       rest: true
> >     }
> >   ],
> >   {
> >     binding: "rest",
> >     rest: true
> >   }
> > ]
> 
> This is missing the default empty array. How would you represent that?

Bug 936219 covers getting access to default values. We could provide it as part of this API by complicating it a bit more or by having the separate API for it. What do you think? With individual field default values, it's starting to make more sense to include them with this API.
You need to log in before you can comment on or make changes to this bug.