>
> Especially since your point seems to be "I don't understand"


Don't make up stories.


> and "it won't help me personally"


Did not state that either.

It's time to take a step back


Not sure what you mean.

On Thu, Jun 20, 2019 at 1:15 AM Frederick Stark <coagmano at gmail.com> wrote:

> You've already made this point, so you're not adding anything new to the
> discussion now. Especially since your point seems to be "I don't
> understand" and "it won't help me personally"
> It's time to take a step back and allow others to discuss. If a formal
> proposal eventuates, you can continue to make your points there
>
> On Jun 20 2019, at 11:05 am, guest271314 <guest271314 at gmail.com> wrote:
>
> 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
>
> _______________________________________________
> 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/1658b7cb/attachment-0001.html>

> Especially since your point seems to be "I don't understand"


Don't make up stories.


> and "it won't help me personally"


Did not state that either.

> It's time to take a step back


Not sure what you mean.