> A module namespace isn’t an instance of Module, it’s a module namespace spec object. If it has a name member, that is because the module you imported has an exported binding called name. But what kind of thing it is isn’t what matters.
If ```Object.getOwnPropertyDescriptors(ns)``` is used within ```<script type="module">``` ```Symbol(Symbol.toStringTag): {value: "Module", writable: false, enumerable: false, configurable: false}``` will also be part of the output. If ```Object.keys(ns)``` is used ```Symbol(Symbol.toStringTag)``` will not be part of output. > Since ```nameof``` does not actually evaluate anything, the following would be legal: > ``` > const x = nameof y; // "y" > const y = 1; > ``` Interesting. ```y``` would be able to be evaluated before ```y``` is defined? On Fri, Jun 14, 2019 at 6:01 PM Stas Berkov <stas.ber...@gmail.com> wrote: > > Is Case 1 equivalent to a briefer version of > > ``` > if (userName == undefined) { > throw new Error(`Argument cannot be null: > ${Object.keys({userName})[0]}`); > } > ``` > Less readable but in this simple case might work. > What if we do the following: > 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 "Argument cannot be null: userName". > } > } > ``` > > Case 2. Accessing property extended info > e.g. > ``` > const descriptor1 = Object.getOwnPropertyDescriptor(object1, 'property1'); > ``` > vs > ``` > const descriptor1 = Object.getOwnPropertyDescriptor(object1, nameof > object1.property1); > ``` > 2nd variant (proposed) has more chances not to be broken during > refactoring (robustness). > > On Fri, Jun 14, 2019 at 9:48 PM Stas Berkov <stas.ber...@gmail.com> wrote: > >> Less fragile. Less mess. You can rename field/property without fear you >> break something (using IDE refactoring tools). >> With high probablity you will break something when you refactor and have >> fields hardcoded as strings. >> Someone can object that you can rename strings as well. >> Issue here that you can ocassionally change non-related strings that >> should not be changed even they match or have matching substring. >> >> On Fri, Jun 14, 2019 at 9:38 PM guest271314 <guest271...@gmail.com> >> wrote: >> >>> Is Case 1 equivalent to a briefer version of >>> >>> ``` >>> if (userName == undefined) { >>> throw new Error(`Argument cannot be null: >>> ${Object.keys({userName})[0]}`); >>> } >>> ``` >>> >>> ? >>> >>> If not, how is ```nameof``` different? >>> >>> What is the difference between the use of >>> ```message.hasOwnProperty(property)``` >>> and ```nameof msg.expiration_utc_time```? >>> >>> > You get more robust code. >>> >>> How is "robust" objectively determined? >>> >>> >>> >>> >>> On Fri, Jun 14, 2019 at 5:21 PM Stas Berkov <stas.ber...@gmail.com> >>> wrote: >>> >>>> ES can befit from `nameof` feature the same way as TS. There is no TS >>>> specific in it. >>>> It was ask to introduce in TS as a workaround since TS is considered as >>>> extention of ES. >>>> >>>> Case 1. Function guard. >>>> ``` >>>> 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". >>>> } >>>> } >>>> ``` >>>> >>>> Case 2. Access extended information an object property. >>>> Assume a function >>>> ``` >>>> function protoPropertyIsSet(message, property) { >>>> return message != null && message.hasOwnProperty(property); >>>> } >>>> ``` >>>> Then in code you use it as `if (protoPropertyIsSet(msg, >>>> "expiration_utc_time")) {... }`. >>>> Having `nameof` would allow you to do that `if (protoPropertyIsSet(msg, >>>> nameof msg.expiration_utc_time)) {... }`. >>>> You get more robust code. >>>> >>>> On Fri, Jun 14, 2019 at 5:46 PM Augusto Moura < >>>> augusto.borg...@gmail.com> wrote: >>>> >>>>> Can you list the benefits of having this operators? Maybe with example >>>>> use cases >>>>> >>>>> If I understand it correctly, the operator fits better in compiled >>>>> (and typed) languages, most of the use cases don't apply to dynamic >>>>> Javascript >>>>> The only legit use case I can think of is helping refactor tools to >>>>> rename properties (but even mismatch errors between strings and >>>>> properties names can be caught in compile time using modern >>>>> Typescript) >>>>> >>>>> Em sex, 14 de jun de 2019 às 10:05, Stas Berkov >>>>> <stas.ber...@gmail.com> escreveu: >>>>> > >>>>> > Can we revisit this issue? >>>>> > >>>>> > >>>>> > In C# there is `nameof`, in Swift you can do the same by calling >>>>> > >>>>> > ``` >>>>> > >>>>> > let keyPath = \Person.mother.firstName >>>>> > >>>>> > NSPredicate(format: "%K == %@", keyPath, "Andrew") >>>>> > >>>>> > ``` >>>>> > >>>>> > Let's introduce `nameof` in ES, please. >>>>> > >>>>> > >>>>> > Devs from TypeScript don't want to introduce this feature in >>>>> TypeScript unless it is available in ES ( >>>>> https://github.com/microsoft/TypeScript/issues/1579 ) >>>>> > >>>>> > This feature is eagarly being asked by TypeScript community. >>>>> > >>>>> > >>>>> > I understand there are couple issues related to `nameof` feature in >>>>> ES. They are: minification and what to do if user already has `nameof` >>>>> function. >>>>> > >>>>> > >>>>> > Minification. >>>>> > >>>>> > 1. If your code to be minimized be prepared that variable names will >>>>> also change. >>>>> > >>>>> > 2. (just a possibility) Minimizer can have option to replace >>>>> `nameof(someVar)` with result of `nameof` function. >>>>> > >>>>> > >>>>> > >>>>> > What if user already has `nameof` function. >>>>> > >>>>> > 1. To maintain status quo we can user `nameof` function having >>>>> priority over newly introduced language feature. >>>>> > >>>>> > 2. OR we can use `typeof` syntax, e.g. `nameof msg.userName` (// >>>>> returns "userName" string) >>>>> > >>>>> > _______________________________________________ >>>>> > es-discuss mailing list >>>>> > es-discuss@mozilla.org >>>>> > https://mail.mozilla.org/listinfo/es-discuss >>>>> >>>>> >>>>> >>>>> -- >>>>> Atenciosamente, >>>>> >>>>> Augusto Borges de Moura >>>>> >>>> _______________________________________________ >>>> 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