`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 <guest271...@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.ber...@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@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss