guest271314 at gmail.com (2019-06-15T22:45:00.607Z)
``` const f = () => y; let y = 1; ``` is different (dissimilar) code from the original example code referenced ``` const x = nameof y; // "y" const y = 1; ``` How is that example related to the ```nameof``` proposal? Does that example seek to extend referencing ```const``` declarations _before_ the initialization? Or, can that example be set aside? Can you kindly clarify how that example is different from attempting to reference a ```const``` variable before initialization (which would, at the outset, be more than simply a ```nameof``` operator)? > I don’t disagree that there are “alternative approaches” to ‘nameof’ for many cases, but they all incur overhead. What overhead is incurred by the approach using ```const```, ```try..catch``` and ```ReferenceError```? Given that a ```ReferenceError``` is thrown _now_ when attempting to reference a variable declared using ```const``` before initialization where the ```message``` property _includes the name of the variable_, either the specification now defines to do so, and, or, the implementers are already getting the name of the idetifier as a string and outputting the expected result of ```nameof``` (identifier name) in a similar context. Thus, the code already exists and is already being implemented at ```ReferenceError```. It would appear it is now a matter of locating that source code in browser implementations and abstracting the process to a ```nameof``` function. Therefore, from the point of view of what potentially already exists in specification and, or is already implemented in browsers, ```nameof``` as a standalone function or operator does not appear to be outside of the scope of what browsers are already doing. Abstracting ```nameof``` to a standalone function should be possible - using what already exists. Have you looked into the source code of browsers that implement ```const``` to determine the issues, if any, as to utilizing the existiing implementation(s) of ```ReferenceError``` to facilitate ```nameof``` while avoiding incurring the described "overhead" of using workarounds to achieve the same output?
guest271314 at gmail.com (2019-06-15T22:33:10.271Z)
``` const f = () => y; let y = 1; ``` is different (dissimilar) code from the original example code referenced ``` const x = nameof y; // "y" const y = 1; ``` > I don’t disagree that there are “alternative approaches” to ‘nameof’ for many cases, but they all incur overhead. What overhead is incurred by the approach using ```const```, ```try..catch``` and ```ReferenceError```? Given that a ```ReferenceError``` is thrown _now_ when attempting to reference a variable declared using ```const``` before initialization where the ```message``` property _includes the name of the variable_, either the specification and, or the implementers are already getting the name of the idetifier as a string and outputing the described requirement of ```nameof``` in a similar context. Thus, the code already exists. It would appear it is now a matter of locating that source code in browser implementations and abstracting the process to a ```nameof``` function or operator. Have you looked into the source code of browsers that implement ```const``` to determine the issues, if any, as to utilizing the existiing implementation(s) of ```ReferenceError``` to facilitate ```nameof``` while avoiding incurring the described "overhead" of using workarounds to achieve the same output?
guest271314 at gmail.com (2019-06-15T22:30:38.405Z)
``` const f = () => y; let y = 1; ``` is different (dissimilar) code from the original example code referenced ``` const x = nameof y; // "y" const y = 1; ``` > I don’t disagree that there are “alternative approaches” to ‘nameof’ for many cases, but they all incur overhead. What overhead is incurred by the approach using ```const```, ```try..catch``` and ```ReferenceError```? Given that a ```ReferenceError``` is thrown when attempting to reference a variable declared using ```const``` before initialization where the ```message``` property includes the name of the variable, either the specification and, or the implementers are already getting the name of the idetifier as a string and outputing the described requirement of ```nameof``` in a similar context. Thus, the code already exists. It would appear it is now a matter of locating that source code in browser implementations and abstracting the process to a ```nameof``` function or operator. Have you looked into the source code of browsers that implement ```const``` to determine the issues, if any, as to utilizing the existiing implementation(s) of ```ReferenceError``` to facilitate ```nameof``` while avoiding incurring the described "overhead" of using workarounds to achieve the same output?
guest271314 at gmail.com (2019-06-15T22:29:10.281Z)
``` const f = () => y; let y = 1; ``` is different (dissimilar) code than the original reference example code. > I don’t disagree that there are “alternative approaches” to ‘nameof’ for many cases, but they all incur overhead. What overhead is incurred by the approach using ```const```, ```try..catch``` and ```ReferenceError```? Given that a ```ReferenceError``` is thrown when attempting to reference a variable declared using ```const``` before initialization where the ```message``` property includes the name of the variable, either the specification and, or the implementers are already getting the name of the idetifier as a string and outputing the described requirement of ```nameof``` in a similar context. Thus, the code already exists. It would appear it is now a matter of locating that source code in browser implementations and abstracting the process to a ```nameof``` function or operator. Have you looked into the source code of browsers that implement ```const``` to determine the issues, if any, as to utilizing the existiing implementation(s) of ```ReferenceError``` to facilitate ```nameof``` while avoiding incurring the described "overhead" of using workarounds to achieve the same output?
guest271314 at gmail.com (2019-06-15T22:28:18.859Z)
``` const f = () => y; let y = 1; ``` is different (dissimilar) code than the original reference example code. > I don’t disagree that there are “alternative approaches” to ‘nameof’ for many cases, but they all incur overhead. What overhead is incurred by the approach using ```const```, ```try..catch``` and ```ReferenceError```? Given that a ```ReferenceError``` is thrown when attempting to reference a variable declared using ```const``` where the ```message``` property includes the name of the variable, either the specification and, or the implementers are already getting the name of the idetifier as a string and outputing the described requirement of ```nameof``` in a similar context. Thus, the code already exists. It would appear it is now a matter of locating that source code in browser implementations and abstracting the process to a ```nameof``` function or operator. Have you looked into the source code of browsers that implement ```const``` to determine the issues, if any, as to utilizing the existiing implementation(s) of ```ReferenceError``` to facilitate ```nameof``` while avoiding incurring the described "overhead" of using workarounds to achieve the same output?
``` const f = () => y; let y = 1; ``` is different (dissimilar) code than the original reference example code. > I don’t disagree that there are “alternative approaches” to ‘nameof’ for many cases, but they all incur overhead. Given that a ```ReferenceError``` is thrown when attempting to reference a variable declared using ```const``` where the ```message``` property includes the name of the variable, either the specification and, or the implementers are already getting the name of the idetifier as a string and outputing the described requirement of ```nameof``` in a similar context. Thus, the code already exists. It would appear it is now a matter of locating that source code in browser implementations and abstracting the process to a ```nameof``` function or operator. Have you looked into the source code of browsers that implement ```const``` to determine the issues, if any, as to utilizing the existiing implementation(s) of ```ReferenceError``` to facilitate ```nameof``` while avoiding incurring the described "overhead" of using workarounds to achieve the same output? On Sat, Jun 15, 2019 at 10:03 PM Ron Buckton <Ron.Buckton at microsoft.com> wrote: > > At that point in the example code the identifer ```y``` does not exist. > > > > That is not entirely incorrect. The identifier `y` exists, but its binding > has not been initialized, otherwise you couldn’t refer to y in this case: > > > > ``` > > const f = () => y; > > let y = 1; > > ``` > > > > > That fact can be utilized for an alternative approach to meet > requirement of "Case 1. Function guard.". > > > > I don’t disagree that there are “alternative approaches” to ‘nameof’ for > many cases, but they all incur overhead. > > > > At the end of the day, ‘nameof’ is a convenience feature that provides an > incremental “quality of life” improvement, much like shorthand property > assignments were a convenience feature (i.e. how hard is it to write `{ > foo: foo }`). It’s not something that would be as much of a game changer to > the language as async/await or yield were, but it would be a fairly easily > spec’d and nice-to-have capability. > > > > *From:* guest271314 <guest271314 at gmail.com> > *Sent:* Saturday, June 15, 2019 2:50 PM > *To:* Ron Buckton <Ron.Buckton at microsoft.com> > *Cc:* es-discuss at mozilla.org > *Subject:* Re: Re: What do you think about a C# 6 like nameof() > expression for > > > > > It doesn’t matter what the *value* of ‘y’ is, just what the lexical > name of `y` is. `nameof` wouldn’t refer to `y` as an expression, its just > pointing to the identifier. > > > > Was not referring to the _value_ of ```y```. At that point in the example > code the identifer ```y``` does not exist. That is, unless there was an > expected presumption that ```y``` was defined globally prior to the > ```const y = 1;``` declaration at the next line. Even then a variable > declared using ```const``` cannot be referenced before "lexical > declaration" or "initialization". That fact can be utilized for an > alternative approach to meet requirement of "Case 1. Function guard.". > Tested at Chromium 76 and Firefox 69. Have not used MS browser (or > browserstack) in some time. Have not tried the code at Safari either, > though the code is capable of adjustment for any JavaScript environment > which throws a ```ReferenceError``` under the same case > > > > ``` > > function func1(param1, param2, param3, userName, param4, param5) { > if (userName === undefined) { > try { > // throws ReferenceError > // Firefox 69: ReferenceError: "can't access lexical declaration > `userName' before initialization" > // Chromium 76: ReferenceError: Cannot access 'userName' before > initialization > const userName = userName; > } catch (e) { > // match identifier at Firefox, Chromium ReferenceError message > // adjust RegExp for IE/Edge, Safari, etc. > const nameof = e.message.match(/(?!`|')[^\s]+(?=')/g).pop(); > throw new Error(`"Argument cannot be null: ${nameof}"`); > } > } else { > // do stuff > console.log(userName); > } > } > > try { > func1(1, 2, 3); // throws error > } catch (e) { > console.error(e); // get name of variable identifier > } > > try { > func1(1, 2, 3, 4); // logs userName at console > } catch (e) { > console.error(e); // should not be reached > } > > ``` > > > > On Sat, Jun 15, 2019 at 9:37 PM Ron Buckton <Ron.Buckton at microsoft.com> > wrote: > > It doesn’t matter what the *value* of ‘y’ is, just what the lexical name > of `y` is. `nameof` wouldn’t refer to `y` as an expression, its just > pointing to the identifier. > > > > *From:* guest271314 <guest271314 at gmail.com> > *Sent:* Friday, June 14, 2019 10:03 PM > *To:* Ron Buckton <Ron.Buckton at microsoft.com> > *Cc:* es-discuss at mozilla.org > *Subject:* Re: Re: What do you think about a C# 6 like nameof() > expression for > > > > > I’m not sure I understand what you mean by “false-positive” in this > instance. > > > > Was referring to > > > > const x = nameof y; // "y" > > const y = 1; > > > > Where ```y``` is ```undefined``` an error is not expected to be thrown? Is > ```y``` declared globally, using ```const``` or ```let```, or not at all? > The use case described by OP > > > > function func1(param1, param2, param3, userName, param4, param5) { > > if (userName == undefined) { > > throw new ArgumentNullError(nameof userName); // `ArgumentNullError` > > is a custom error, derived from `Error`, composes error message like > > "Argument cannot be null: userName". > > } > > checks if ```userName``` was ```undefined``` before using ```nameof```. > If error checking is a substantial portion of the proposal, why should an > error (```y``` being ```undefined``` though referenced) be ignored when > referencing an undefined identifier though concentrate on coercing a name > from a different potentially undefined property? > > > > Consider this case: > ``` > const someObject = { value: 1 }; > function setValue(value /*1*/) { > if (typeof value /*2*/ !== "number") throw new TypeError(`Number > expected: ${nameof value /*3*/}`); > someObject["value" /*4*/] = value /*5*/; > } > ``` > > If you rename the parameter `value` of the function `setValue` in an > editor with a rename refactoring, you want to rename the symbols at 1, 2, > 3, and 5, but not the string at 4. > > > > Not gathering the purpose or value of ```nameof``` usage in that case. If > the value is not a "number" then why does the value or name matter? > > > > Since the primary use case appears to be an editor environment, why cannot > the editor be programmed to recognize the custom JavaScript ```nameof```` > function or operator? Then it would not matter if this board concurred with > the ```nameof``` functionality or not. Both CLI and GUI editors (and > JavaScript) are generally extensible. FWIW, some time ago incorporated > features into gedit for HTML templates; should be a similar process to > create custom scripts for the various editor environments where users rely > on such programs for code composition; now simply write the code by hand > and test in different environments, without taking the time to customize or > rely on an editor - take the time to test the code where the code will > actually be run where errors, if any, can be evaluated in the context in > which a specific output is expected. To each their own. What needs to be > implemented outside of what the users which advocate for ```nameof``` > cannot implement themselves? > > > > As mentioned earlier do not rely on "an editor with name refactoring" to > compose code. The code has to be tested (outside of the editor > environments) anyway. Test the code itself, here, not the editor. > > > > On Fri, Jun 14, 2019 at 9:49 PM Ron Buckton <Ron.Buckton at microsoft.com> > wrote: > > I’m not sure I understand what you mean by “false-positive” in this > instance. > > > > Consider this case: > > > > ``` > > const someObject = { value: 1 }; > > function setValue(value /*1*/) { > > if (typeof value /*2*/ !== "number") throw new TypeError(`Number > expected: ${nameof value /*3*/}`); > > someObject["value" /*4*/] = value /*5*/; > } > > ``` > > > > If you rename the parameter `value` of the function `setValue` in an > editor with a rename refactoring, you want to rename the symbols at 1, 2, > 3, and 5, but not the string at 4. > > > > Ron > > > > *From:* guest271314 <guest271314 at gmail.com> > *Sent:* Friday, June 14, 2019 2:43 PM > *To:* Ron Buckton <Ron.Buckton at microsoft.com> > *Cc:* es-discuss at mozilla.org > *Subject:* Re: Re: What do you think about a C# 6 like nameof() > expression for > > > > How is that behaviour related to the use cases presented by OP? Would such > behaviour not lead to false-positive relevant to the 2 use cases? > > > > On Fri, Jun 14, 2019 at 9:36 PM Ron Buckton <Ron.Buckton at microsoft.com> > wrote: > > > `nameof whatever` → `Object.keys({ whatever })[0]`, but I'm a bit > confused why it'd be better to type `nameof foo` in code, rather than > `'foo'` - if you change `foo` to `bar`, you have to change both of them > anyways. > > > > If you are using an editor that supports rename refactoring, its generally > easier to rename the symbol `foo` and have all references (including > `nameof foo`) be updated. You cannot safely automatically rename `'foo'` to > `'bar'` since an editor or language service cannot guarantee that by the > string `'foo'` you meant “the text of the identifier `foo`”. > > > > *From:* es-discuss <es-discuss-bounces at mozilla.org> *On Behalf Of *Jordan > Harband > *Sent:* Friday, June 14, 2019 2:29 PM > *To:* guest271314 <guest271314 at gmail.com> > *Cc:* es-discuss <es-discuss at mozilla.org> > *Subject:* Re: Re: What do you think about a C# 6 like nameof() > expression for > > > > `nameof whatever` → `Object.keys({ whatever })[0]`, but I'm a bit confused > why it'd be better to type `nameof foo` in code, rather than `'foo'` - if > you change `foo` to `bar`, you have to change both of them anyways. > > > > On Fri, Jun 14, 2019 at 1:31 PM guest271314 <guest271314 at gmail.com> wrote: > > Am neither for nor against the proposal. Do not entertain "like"s or > "dislike"s in any field of endeavor. Am certainly not in a position to > prohibit anything relevant JavaScript. Do what thou wilt shall be the whole > of the Law. > > Have yet to view a case where code will be "broken" by ```nameof``` not > being a JavaScript feature. "robustness", as already mentioned, is a > subjective adjective that is not capable of being objectively evaluated as > to code itself. That description is based on preference or choice. > > > > In lieu of the proposal being specificed, use the posted code example of > ```Object.keys()``` that "works". > > > > ``` > > function func1({userName = void 0} = {}) { > console.assert(userName !== undefined, [{userName}, 'property needs to > be defined']) > } > > ``` > > > > provides a direct indication that the property value is required to be > defined. Note that the example code posted thus far does not first check if > ```options``` is passed at all, for which ```nameof``` will not provide any > asssitance. > > > > Usually try to meet requirement by means already available in FOSS > browsers. Have no interest in TypeScript or using an IDE. > > > > FWIW, have no objection to the proposal. > > > > On Fri, Jun 14, 2019 at 7:53 PM Stas Berkov <stas.berkov at gmail.com> wrote: > > guest271314, what is you point against `nameof` feature? > > If you don't like it - don't use it. Why prohibit this feature for > those who find it beneficial? > > I see `nameof` beneficial in following cases > > Case 1. Function guard. > ``` > function func1(options) { > ... > if (options.userName == undefined) { > throw new ParamNullError(nameof options.userName); // > `ParamNullError` is a custom error, derived from `Error`, composes > error message like "Parameter cannot be null: userName". > // `Object.keys({options.userName})[0]` will not work here > } > } > ``` > > Case 2. Accessing property extended info > Those ES functions that accept field name as string. > e.g. > ``` > const descriptor1 = Object.getOwnPropertyDescriptor(object1, 'property1'); > ``` > vs > ``` > const descriptor1 = Object.getOwnPropertyDescriptor(object1, nameof > object1.property1); > // `Object.keys({options1.property1})[0]` will not work here > ``` > 2nd variant (proposed) has more chances not to be broken during > refactoring (robustness). > > It would make devs who use IDE more productive and make their life > easier. Why not give them such possiblity and make them happy? > > _______________________________________________ > es-discuss mailing list > es-discuss at mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.mozilla.org%2Flistinfo%2Fes-discuss&data=02%7C01%7CRon.Buckton%40microsoft.com%7C4036bd0c96744cab8c4208d6f1db7291%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636962322162641169&sdata=U%2B%2Fq939hNKeRQlHnXNvoEPvcoi01IR3T56Jv7eOJSlg%3D&reserved=0> > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20190615/70cdf24e/attachment-0001.html>