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