5 ms·

Funny. If this is effectively so, the code is actually fairly ok and clearly expresses the intent for humans yet the OP claiming exactly that managed to still m

by stinos 3y ago

Funny. If this is effectively so, the code is actually fairly ok and clearly expresses the intent for humans yet the OP claiming exactly that managed to still misunderstand the code because they made up a precondition ('defaultValue is going to be a number') probably exactly because they refused to 'To answer this question, you need to start looking around for clues' so they missed the clue [1]; or maybe rather the clue is: dynamically typed so expecting a number is a wrong assumption. Still I'd argue a comment explaining why it's in this particular case fine that any non-sane input translates to NaN and not an error might be worth it Well, unless that is clear from the surrounding code :)

cxr 3y ago
> dynamically typed so[...] People accustomed to strongly typed languages and thinking mostly of monolithic apps always pin things on dynamic typing even where it's not the cause. It's not about dynamic typing in this case. What's going on here is partially because of separate compilation and partially because of mobile code (as Lars Bak explains[1]). Even if developing in a strongly typed language, the machinery would still have to take care to deal with the same thing. In fact, this isn't even JS; this file is TypeScript—and this expression being strongly typed is almost certainly exactly why this code was written this way: because `useControlledState<number>` demands it. If `useControlledState` were just vanilla JS and no one were doing typechecking during development and build, there would have been no problem with passing something else as an argument, because it will of course evaluate to NaN anyway when undergoing the number treatment. (This is kind of subtle, but it's not that subtle. Too many people make this mistake, and there's probably something that needs to be done about that; "because dynamic languages" has become something of a thought-terminating cliché that leads people to the wrong conclusions—as demonstrated even in the interview, at the point where Bak felt prompted to point this out.) 1. Inside V8 — A Javascript Virtual Machine. Going Deep: Expert to Expert. Accessed July 3, 2020. <https://channel9.msdn.com/Shows/Going+Deep/Expert-to-Expert-Erik-Meijer-and-Lars-Bak-Inside-V8-A-Javascript-Virtual-Machine https://channel9.msdn.com/Shows/Going+Deep/Expert-to-Expert-...>.
- stinos 3y ago
  Funny. Seems I fell into the same trap I just sketched, making wrong assumptions because of not looking around in the code. But to be honest from your explanation I still cannot tell whether I merely used incorrect terminology wrt dynamic typing (but the general principle still holding) or whether this code guarantees that defaultValue is in fact always a numeric type?
  - cxr 3y ago
    This code doesn't. It guarantees that within `useControlledState`[1], `defaultValue` is either NaN, an actual number, a number-like string, or something else that can be coerced into one[2]. If `defaultValue` is, for example, `true` or even an empty array, then the result of the expression `isNaN(defaultValue) ? NaN : defaultValue` will pass through `true` or the empty array. 1. <https://github.com/adobe/react-spectrum/blob/main/packages/%40react-stately/utils/src/useControlledState.ts https://github.com/adobe/react-spectrum/blob/main/packages/%...> 2. whether one of those non-numbers is prevented from actually making an appearance at this point for other _reasons_ is a different question, but the fact remains that one making its way through is not something that would be stopped from proceeding further by the isNaN check here (Addendum to, I hope, clarify: I'll reiterate that it's the type annotations on the `useControlledState` call site parameterized as `useControlledState<number>` (and the TypeScript team's decision to type `isNaN` to take only parameters with a number type) that "guarantees" `defaultValue` is a number. But that guarantee is a soft one, i.e. not a guarantee at all, precisely because of mobile code and separate compilation; I can contrive a project right now that uses the Adobe Spectrum library and pass whatever I want to it—it's not like the Adobe devs' compilers are going to be able to stop me.)
    - deleted 3y ago
      [deleted]
- cxr 3y ago
  PS: Gilad Bracha makes a similar point in this interview about pluggable types: Newspeak and Pluggable Types. Software Engineering Radio. IEEE Computer Society. <https://www.se-radio.net/2009/07/episode-140-newspeak-and-pluggable-types-with-gilad-bracha/ https://www.se-radio.net/2009/07/episode-140-newspeak-and-pl...>.

by stinos 3y ago

cxr 3y ago

> dynamically typed so[...] People accustomed to strongly typed languages and thinking mostly of monolithic apps always pin things on dynamic typing even where it's not the cause. It's not about dynamic typing in this case. What's going on here is partially because of separate compilation and partially because of mobile code (as Lars Bak explains[1]). Even if developing in a strongly typed language, the machinery would still have to take care to deal with the same thing. In fact, this isn't even JS; this file is TypeScript—and this expression being strongly typed is almost certainly exactly why this code was written this way: because `useControlledState<number>` demands it. If `useControlledState` were just vanilla JS and no one were doing typechecking during development and build, there would have been no problem with passing something else as an argument, because it will of course evaluate to NaN anyway when undergoing the number treatment. (This is kind of subtle, but it's not that subtle. Too many people make this mistake, and there's probably something that needs to be done about that; "because dynamic languages" has become something of a thought-terminating cliché that leads people to the wrong conclusions—as demonstrated even in the interview, at the point where Bak felt prompted to point this out.) 1. Inside V8 — A Javascript Virtual Machine. Going Deep: Expert to Expert. Accessed July 3, 2020. <https://channel9.msdn.com/Shows/Going+Deep/Expert-to-Expert-Erik-Meijer-and-Lars-Bak-Inside-V8-A-Javascript-Virtual-Machine https://channel9.msdn.com/Shows/Going+Deep/Expert-to-Expert-...>.

stinos 3y ago
Funny. Seems I fell into the same trap I just sketched, making wrong assumptions because of not looking around in the code. But to be honest from your explanation I still cannot tell whether I merely used incorrect terminology wrt dynamic typing (but the general principle still holding) or whether this code guarantees that defaultValue is in fact always a numeric type?
- cxr 3y ago
  This code doesn't. It guarantees that within `useControlledState`[1], `defaultValue` is either NaN, an actual number, a number-like string, or something else that can be coerced into one[2]. If `defaultValue` is, for example, `true` or even an empty array, then the result of the expression `isNaN(defaultValue) ? NaN : defaultValue` will pass through `true` or the empty array. 1. <https://github.com/adobe/react-spectrum/blob/main/packages/%40react-stately/utils/src/useControlledState.ts https://github.com/adobe/react-spectrum/blob/main/packages/%...> 2. whether one of those non-numbers is prevented from actually making an appearance at this point for other _reasons_ is a different question, but the fact remains that one making its way through is not something that would be stopped from proceeding further by the isNaN check here (Addendum to, I hope, clarify: I'll reiterate that it's the type annotations on the `useControlledState` call site parameterized as `useControlledState<number>` (and the TypeScript team's decision to type `isNaN` to take only parameters with a number type) that "guarantees" `defaultValue` is a number. But that guarantee is a soft one, i.e. not a guarantee at all, precisely because of mobile code and separate compilation; I can contrive a project right now that uses the Adobe Spectrum library and pass whatever I want to it—it's not like the Adobe devs' compilers are going to be able to stop me.)
  - deleted 3y ago
    [deleted]
cxr 3y ago
PS: Gilad Bracha makes a similar point in this interview about pluggable types: Newspeak and Pluggable Types. Software Engineering Radio. IEEE Computer Society. <https://www.se-radio.net/2009/07/episode-140-newspeak-and-pluggable-types-with-gilad-bracha/ https://www.se-radio.net/2009/07/episode-140-newspeak-and-pl...>.