guest271314 (2019-06-20T01:05:49.000Z)
The current proposal is redundant.  The user has to already know and write
the exact name of the variable, or try to guess the variable name to not,
or to, catch an error that includes the name of the identifier as a
string.  Why should the user have to already know any write the variable as
a literal? If that feature is valuable to users of JavaScript by all means
write that definition.

Extending the original proposal with the ability for the user to use
```nameof``` to get list of all varibales declared using ```const``` and
```let``` without having to already know and write the exact variable name,
that is, when called without an adjacent exact variable identifier, e.g.,
```const nameofall = nameof *; // ["y", "x"] which can also include line
number```, as well, would not be redundant, and would also benefit users of
JavaScript directly where defining the feature would provide values that
are not currently possible (without previously knowing and writing the
exact name of the variable identifier, or guessing the names of the
identifiers, which should be also already be possible).

On Wed, Jun 19, 2019 at 6:31 PM Isiah Meadows <isiahmeadows at gmail.com>
wrote:

> I get yet again that the forest here is being missed for the trees.
>
> @guest271314 This isn't specific to any one IDE, and isn't even
> specific to static tools. As mentioned before, this has applicability
> to assertion libraries (like a userland version of Power Assert) as
> well as other things. It's almost exclusively just quality-of-life
> improvements to developers, but it's not specific to IDEs or even
> static tooling.
>
> -----
>
> Isiah Meadows
> contact at isiahmeadows.com
> www.isiahmeadows.com
>
> On Mon, Jun 17, 2019 at 8:28 PM guest271314 <guest271314 at gmail.com> wrote:
> >
> >
> > > You have ignored the context from Jordan’s email (emphasis added):
> >
> >
> >
> > >> again, `Object.keys({ y })[0]` will give you the string `y`, and will
> survive refactoring tools. you can even do `function nameof(obj) { return
> Object.keys(obj)[0]; }` and then `nameof({ y })`.
> >
> >
> > No, did not _ignore_ the context of the email.
> >
> >
> > Simply have no reference point for relying on an external tool, that is,
> essentially a text editor, to write and dynamically "refactor" code. Here,
> the code will be tested outside of the text editor in short order once
> composed.
> >
> >
> > Was able to rename text at Mousepad and record the entire process within
> 20 seconds without needing to use ```nameof``` and without encountering any
> issues such as mispelling the variable name or the text editor trying to
> independently determine what the words am typing mean. The text editor is
> just - a text editor.
> >
> >
> > Perhaps other JavaScript users who rely on "refactoring tools" and
> "rename refactoring" in an IDE can relate. Not able to gather the
> significance of ```nameof``` here - as in each case the user has to write
> the name of the variable anyway. To each their own.
> >
> >
> > > VSCode is a popular editor that supports JavaScript *and* is a
> refactoring tool. Rename refactoring was the subject I was responding to.
> >
> >
> >
> >
> >
> > Was not previously aware or did not realize that the _individual choice_
> to use a particular text editor was a substantial reason to ask for change
> to the entire JavaScript language in order for specific users to be able to
> interact with an entirely different language.
> >
> >
> > If VSCode is particularly "popular" why cannot VSCode be specified and
> implemented by and for the users who rely on the text editor to interpret
> what the users' intent is when writing code.
> >
> >
> > In that case  ```mkvmerge``` should be specified as a JavaScript method.
> ```webm``` is a "popular" (cannot help but to recollect "Popularity"
> https://brendaneich.com/2008/04/popularity/) video container that is a
> subset of the Matroska container, where if that method were specified in
> JavaScript a user would be able to do ```mkvmerge({w: true, o:
> "int_all.webm":  i: ["int.webm", "int1.webm", ...."intN.webm"]})``` instead
> of ```$ mkvmerge -w -o int_all.webm int.webm + int1.webm``` at
> ```terminal```.
> >
> >
> >
> >
> > On Mon, Jun 17, 2019 at 11:29 PM Ron Buckton <Ron.Buckton at microsoft.com>
> wrote:
> >>
> >> > How is VSCode related to JavaScript?
> >>
> >>
> >>
> >> You have ignored the context from Jordan’s email (emphasis added):
> >>
> >>
> >>
> >> >> again, `Object.keys({ y })[0]` will give you the string `y`, and
> will survive refactoring tools. you can even do `function nameof(obj) {
> return Object.keys(obj)[0]; }` and then `nameof({ y })`.
> >>
> >>
> >>
> >> VSCode is a popular editor that supports JavaScript *and* is a
> refactoring tool. Rename refactoring was the subject I was responding to.
> >>
> >>
> >>
> >> There are a number of reasons VSCode has implemented rename refactoring
> in this fashion. Not the least of which is that an editor cannot fully
> understand user intent. Let us say, for example, you are working with Gulp:
> >>
> >>
> >>
> >> ```
> >>
> >> const cwd /*1*/ = ".";
> >>
> >> gulp.src("*.js", { cwd /*2*/ });
> >>
> >> ```
> >>
> >>
> >>
> >> If you were to rename `cwd` at (1) and it *also* renamed the `cwd`
> property at (2), you would have introduced an error in the call because a
> `cwd` option to gulp has a special meaning. Since the editor doesn’t know
> the intent of the user may be to rename *both* symbols, it remains
> conservative and choses only to rename the binding and its references,
> producing:
> >>
> >>
> >>
> >> ```
> >>
> >> const currentDir = ".";
> >>
> >> gulp.src("*.js", { cwd: currentDir });
> >>
> >> ```
> >>
> >>
> >>
> >> There is also the issue of collisions:
> >>
> >>
> >>
> >> ```
> >>
> >> const foo /*1*/ = 1;
> >>
> >> f({ foo /*2*/, bar: 2 });
> >>
> >> ```
> >>
> >>
> >>
> >> If I were to use a refactoring tool to rename `foo` at (1) to `bar`, it
> would *not* be safe to rename the property at (2) as well as it would
> introduce a semantic error that would prevent the entire script from
> executing.
> >>
> >>
> >>
> >> In the context of Jordan’s email, that means that `Object.keys({ y
> })[0]` would *not* necessarily survive refactoring tools.
> >>
> >>
> >>
> >> From: es-discuss <es-discuss-bounces at mozilla.org> On Behalf Of
> guest271314
> >> Sent: Monday, June 17, 2019 7:40 AM
> >> Cc: es-discuss at mozilla.org
> >> Subject: Re: Re: What do you think about a C# 6 like nameof()
> expression for
> >>
> >>
> >>
> >> > In VSCode, if you rename ‘foo’ to ‘bar’ at /1/, you get this:
> >>
> >>
> >>
> >> How is VSCode related to JavaScript?
> >>
> >>
> >>
> >> Is the proposal really based on creating ```nameof``` in JavaScript to
> workaround output at a text editor?
> >>
> >>
> >>
> >> Why not file a bug with the individuals who write the code for VSCode
> or just write a text editor code from scratch which does what you want as
> to "refactoring". Or write the code by hand and test the code  to avoid
> having to rely on _any_ text editor to catch your mistakes?
> >>
> >>
> >>
> >>
> >
> > _______________________________________________
> > es-discuss mailing list
> > es-discuss at mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20190620/36c6a4af/attachment-0001.html>
guest271314 at gmail.com (2019-06-20T01:19:37.783Z)
The current proposal is redundant.  The user has to already know and write
the exact name of the variable, or try to guess the variable name to not,
or to, catch an error that includes the name of the identifier as a
string.  Why should the user have to already know and write the variable as
a literal? If the use case is for an assertion, the only way the test could fail is if the developer intentionally wrote the incorrect variable identifer. How can the user know know the exact identifier execpt for writing and reading the code before using ```nameof``` without an error being thrown? If that feature is valuable to users of JavaScript by all means
write that definition.

Extending the original proposal with the ability for the user to use
```nameof``` to get list of all varibales declared using ```const``` and
```let```, ```class```, ```var```, et al., without having to already know and write the exact variable name,
that is, when called without an adjacent exact variable identifier, e.g.,
```const nameofall = nameof *; // ["y", "x"] which can also include line number``` as well, would not be redundant, and would also benefit users of JavaScript directly where defining the feature would provide values that
are not currently possible (without previously knowing and writing the
exact name of the variable identifier, or guessing the names of the
identifiers, which should be also already be possible).
guest271314 at gmail.com (2019-06-20T01:14:40.353Z)
The current proposal is redundant.  The user has to already know and write
the exact name of the variable, or try to guess the variable name to not,
or to, catch an error that includes the name of the identifier as a
string.  Why should the user have to already know any write the variable as
a literal? How can the user know know the exact identifier execpt for writing and reading the code before using ```nameof``` without an error being thrown? If that feature is valuable to users of JavaScript by all means
write that definition.

Extending the original proposal with the ability for the user to use
```nameof``` to get list of all varibales declared using ```const``` and
```let```, ```class```, ```var```, et al., without having to already know and write the exact variable name,
that is, when called without an adjacent exact variable identifier, e.g.,
```const nameofall = nameof *; // ["y", "x"] which can also include line number``` as well, would not be redundant, and would also benefit users of JavaScript directly where defining the feature would provide values that
are not currently possible (without previously knowing and writing the
exact name of the variable identifier, or guessing the names of the
identifiers, which should be also already be possible).
guest271314 at gmail.com (2019-06-20T01:14:09.690Z)
The current proposal is redundant.  The user has to already know and write
the exact name of the variable, or try to guess the variable name to not,
or to, catch an error that includes the name of the identifier as a
string.  Why should the user have to already know any write the variable as
a literal? How can the user know know the exact identifier execpt for writing and reading the code before using ```nameof``` without an error being thrown? If that feature is valuable to users of JavaScript by all means
write that definition.

Extending the original proposal with the ability for the user to use
```nameof``` to get list of all varibales declared using ```const``` and
```let```, ```class``, ```var```, et al., without having to already know and write the exact variable name,
that is, when called without an adjacent exact variable identifier, e.g.,
```const nameofall = nameof *; // ["y", "x"] which can also include line number``` as well, would not be redundant, and would also benefit users of JavaScript directly where defining the feature would provide values that
are not currently possible (without previously knowing and writing the
exact name of the variable identifier, or guessing the names of the
identifiers, which should be also already be possible).
guest271314 at gmail.com (2019-06-20T01:13:11.941Z)
The current proposal is redundant.  The user has to already know and write
the exact name of the variable, or try to guess the variable name to not,
or to, catch an error that includes the name of the identifier as a
string.  Why should the user have to already know any write the variable as
a literal? How can the user know know the exact identifier execpt for writing and reading the code before using ```nameof``` without an error being thrown? If that feature is valuable to users of JavaScript by all means
write that definition.

Extending the original proposal with the ability for the user to use
```nameof``` to get list of all varibales declared using ```const``` and
```let``` without having to already know and write the exact variable name,
that is, when called without an adjacent exact variable identifier, e.g.,
```const nameofall = nameof *; // ["y", "x"] which can also include line number``` as well, would not be redundant, and would also benefit users of JavaScript directly where defining the feature would provide values that
are not currently possible (without previously knowing and writing the
exact name of the variable identifier, or guessing the names of the
identifiers, which should be also already be possible).
guest271314 at gmail.com (2019-06-20T01:11:36.164Z)
The current proposal is redundant.  The user has to already know and write
the exact name of the variable, or try to guess the variable name to not,
or to, catch an error that includes the name of the identifier as a
string.  Why should the user have to already know any write the variable as
a literal? How can the user know knwo the exact identifier execpt for writing and reading the code before using ```nameof```. If that feature is valuable to users of JavaScript by all means
write that definition.

Extending the original proposal with the ability for the user to use
```nameof``` to get list of all varibales declared using ```const``` and
```let``` without having to already know and write the exact variable name,
that is, when called without an adjacent exact variable identifier, e.g.,
```const nameofall = nameof *; // ["y", "x"] which can also include line number``` as well, would not be redundant, and would also benefit users of JavaScript directly where defining the feature would provide values that
are not currently possible (without previously knowing and writing the
exact name of the variable identifier, or guessing the names of the
identifiers, which should be also already be possible).
guest271314 at gmail.com (2019-06-20T01:08:47.100Z)
The current proposal is redundant.  The user has to already know and write
the exact name of the variable, or try to guess the variable name to not,
or to, catch an error that includes the name of the identifier as a
string.  Why should the user have to already know any write the variable as
a literal? If that feature is valuable to users of JavaScript by all means
write that definition.

Extending the original proposal with the ability for the user to use
```nameof``` to get list of all varibales declared using ```const``` and
```let``` without having to already know and write the exact variable name,
that is, when called without an adjacent exact variable identifier, e.g.,
```const nameofall = nameof *; // ["y", "x"] which can also include line number``` as well, would not be redundant, and would also benefit users of JavaScript directly where defining the feature would provide values that
are not currently possible (without previously knowing and writing the
exact name of the variable identifier, or guessing the names of the
identifiers, which should be also already be possible).
guest271314 at gmail.com (2019-06-20T01:07:36.590Z)
The current proposal is redundant.  The user has to already know and write
the exact name of the variable, or try to guess the variable name to not,
or to, catch an error that includes the name of the identifier as a
string.  Why should the user have to already know any write the variable as
a literal? If that feature is valuable to users of JavaScript by all means
write that definition.

Extending the original proposal with the ability for the user to use
```nameof``` to get list of all varibales declared using ```const``` and
```let``` without having to already know and write the exact variable name,
that is, when called without an adjacent exact variable identifier, e.g.,
```const nameofall = nameof *; // ["y", "x"] which can also include line number```

as well, would not be redundant, and would also benefit users of
JavaScript directly where defining the feature would provide values that
are not currently possible (without previously knowing and writing the
exact name of the variable identifier, or guessing the names of the
identifiers, which should be also already be possible).