stas.berkov at gmail.com (2019-06-14T18:04:39.775Z)
> 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 "Parameter 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).stas.berkov at gmail.com (2019-06-14T18:04:19.135Z)
> 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 "Parameter 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).stas.berkov at gmail.com (2019-06-14T18:03:59.892Z)
> 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).stas.berkov at gmail.com (2019-06-14T18:03:37.317Z)
> 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).
> 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.berkov at 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 <guest271314 at 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.berkov at 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.borgesm at 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.berkov at 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 at mozilla.org >>>> > https://mail.mozilla.org/listinfo/es-discuss >>>> >>>> >>>> >>>> -- >>>> Atenciosamente, >>>> >>>> Augusto Borges de Moura >>>> >>> _______________________________________________ >>> es-discuss mailing list >>> es-discuss at mozilla.org >>> https://mail.mozilla.org/listinfo/es-discuss >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20190614/f2ee6891/attachment.html>