Re: Re: What do you think about a C# 6 like nameof() expression for
> 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
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 * 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
RE: Re: What do you think about a C# 6 like nameof() expression for
> … there'd need to be overwhelming evidence that this pattern is commonly used
> enough …
As it pertains to C#: https://github.com/search?l=C%23=nameof=Code.
There are at least 860k uses of the `nameof` operator in C# projects on GitHub,
and that’s before GitHub search gave up because there were too many results and
the search took too long:
[cid:image001.png@01D5252A.DFBBAB10]
There’s unfortunately no way to check for this pattern in JavaScript because
the feature doesn’t exist.
From: es-discuss On Behalf Of Jordan Harband
Sent: Sunday, June 16, 2019 10:35 PM
To: Frederick Stark
Cc: es-discuss@mozilla.org
Subject: Re: Re: What do you think about a C# 6 like nameof() expression for
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 })`.
Obviously it's slightly less ergonomic than `nameof y` would be - but adding
new syntax is very expensive, so there'd need to be overwhelming evidence that
this pattern is commonly used enough, and that userland workarounds like my
`nameof` function were insufficient.
On Sun, Jun 16, 2019 at 10:13 PM Frederick Stark
mailto:coagm...@gmail.com>> wrote:
> > your examples are all completely incorrect anyway
> "incorrect" as to precisely what?
Keep reading the email mate.
Incorrect as to your understanding of how the language works and at what point
variables are defined.
> The user MUST _already_ know the _exact_ identifier name
It's not an issue to need to know the name of the identifier. In fact, as you
correctly pointed out, it's necessary.
If I'm understanding it correctly, the value of the proposal is to make it
easier to refactor (especially with variable renaming tools) without leaving
behind string literals that no longer match the variable name.
I've run into this issue before, but it's been a relatively minor pain for me
personally. So I can see some use for the proposal, though I suspect it would
see most of it's use in tooling.
On the other hand, it might add unnecessary complexity to the language, which
should be avoided.
Overall I'm very mildly supportive.
> That leaves the use case of getting ALL of the names of the identifiers in
> the current scope
I have not seen anyone proposing this, so there's no reason to criticize it yet.
Obligatory disclaimer: not a TC39 member, no decision making power or influence
on process
On Jun 17 2019, at 2:42 pm, guest271314
mailto:guest271...@gmail.com>> wrote:
The user MUST _already_ know the _exact_ identifier name or an error will be
thrown for the original proposal and additional use case for ```nameof```
const x = nameof y; // "y"
const y = 1;
making the need for ```nameof``` moot given that the user cannot then
rationally state that the identifier as a _string_ will somehow be mispelled if
they are able to write the _exact_ name of the identifer at ```nameof``` 100%
of the time.
That leaves the use case of getting ALL of the names of the identifiers in the
current scope
// NAMEOF is always dynamic list of let, const declarations in current scope
console.log(NAMEOF); // ["x", "y"]; [{name:"x", line:5}, {name:"y", line:7}]
// should resolve be in the list even if not declared using const or let?
await new Promise(resolve => setTimeout(resolve, Math.floor(Math.random() *
1000)));
const x = nameof y
await new Promise(resolve => setTimeout(resolve, Math.floor(Math.random() *
1000)));
const y = 1;
without having to already know the name of the identifiers, as is required by
the original proposal, which essentially negates itself as the string literal
```'y'``` is briefer than ```nameof y```.
On Mon, Jun 17, 2019 at 4:19 AM Frederick Stark
mailto:coagm...@gmail.com>> wrote:
guest271314, your examples are all completely incorrect anyway since all
variable declarations (including let and const) are hoisted to the top of the
scope, so when nameof y is evaluated, y is already declared in the scope.
The special behaviour introduced with let and const is that they set up a
"Temporal Dead Zone" where attempts to set or get their value before the line
where they are declared in code throws an exception.
Since nameof doesn't care about the value, only the name of the variable, it
would not need to throw an exception.
Of course, were this proposal to be taken seriously, it could be specced either
way
On Jun 17 2019, at 10:15 am, guest271314
mailto:guest271...@gmail.com>> wrote:
> - If `y` is directly visible in scope and is neither a parameter or
destructured binding, `nameof y` should just evaluate to `"y"`. This
should be agnostic to whether the binding has been declared yet, so in
your example, `x` should be set to `"y"`.
The 1st question at
RE: Re: What do you think about a C# 6 like nameof() expression for
> 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 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
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
