ES Discuss - Message History

guest271314 (2019-06-14T19:08:53.000Z)

Go to Source

> 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.berkov 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]}`);
>    }
> ```
> 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/d9783906/attachment.html>

guest271314 at gmail.com (2019-06-14T19:24:27.900Z)

> 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">``` then ```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.

Good points about the overhead of using existing JavaScript features as substitute for ```nameof```. Considered that when composing the code. Still not sure what exactly the use of ```nameof``` is outside of an IDE environment?

> 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 ```const y = 1``` is
defined?

Or, is the output of ```nameof y``` not related to the ```const``` variable declaration ```y``` defined at the next line? 

If that example is correct as to expected output, would that not lead to false-positive as to ```y``` being defined or not? That is, what occurs if the second line does not exist in the code?

guest271314 at gmail.com (2019-06-14T19:22:20.182Z)

> 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">``` then ```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 ```const y = 1``` is
defined?

Or, is the output of ```nameof y``` not related to the ```const``` variable declaration ```y``` defined at the next line? 

If that example is correct as to expected output, would that not lead to false-positive as to ```y``` being defined or not? That is, what occurs if the second line does not exist in the code?

guest271314 at gmail.com (2019-06-14T19:15:08.275Z)

> 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">``` then ```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?

Or, is the output of ```nameof y``` not related to the variable ```y``` defined at the next line? 

If that example is correct as to expected output, would that not lead to false-positive as to ```y``` being defined or not? That is, what occurs if the second line does not exist in the code?

guest271314 at gmail.com (2019-06-14T19:12:08.198Z)

> 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">``` then ```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?

guest271314 at gmail.com (2019-06-14T19:11:49.331Z)

> 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 ```<scripttype="module">``` then ```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?

Edit