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
cont...@isiahmeadows.com
www.isiahmeadows.com
On Mon, Jun 17, 2019 at 8:28 PM guest271314 <guest271...@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.buck...@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-boun...@mozilla.org> On Behalf Of guest271314
>> Sent: Monday, June 17, 2019 7:40 AM
>> Cc: es-discuss@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@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
