`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
