V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
推荐关注
Meteor
JSLint - a JavaScript code quality tool
jsFiddle
D3.js
WebStorm
推荐书目
JavaScript 权威指南第 5 版
Closure: The Definitive Guide
ufo5260987423
V2EX  ›  JavaScript

讨论: JS 程序员觉得 RuntimeTypeInspector.js 怎样?

  •  
  •   ufo5260987423 · 316 天前 · 2120 次点击
    这是一个创建于 316 天前的主题,其中的信息可能已经有所发展或是发生改变。

    https://runtimetypeinspector.org/ 里面说 RuntimeTypeInspector.js 配合 babel.js 等工具能够生成类型断言。这些断言将被用于在运行时,以避免错误或给出有效报错信息。

    网站给出的典型案例是: 在 js 代码中手动添加类型标注如

    /**
     * @param {number} a
     * @param {number} b
     */
    function add(a, b) {
      return a + b;
    }
    /** @type {number[]} */
    const arr = [10_20];
    const [a, b] = arr;
    const ret = add(a, b);
    console.log("ret", ret);
    

    生成

    import {inspectType, youCanAddABreakpointHere, registerVariable, validateDivision, registerTypedef, registerClass} from '@runtime-type-inspector/runtime';
    export * from '@runtime-type-inspector/runtime';
    
    /**
     * @param {number} a
     * @param {number} b
     */
    function add(a, b) {
      if (!inspectType(a, "number", 'add', 'a')) {
        youCanAddABreakpointHere();
      }
      if (!inspectType(b, "number", 'add', 'b')) {
        youCanAddABreakpointHere();
      }
      return a + b;
    }
    /** @type {number[]} */
    
    const arr = [10_20];
    const [a, b] = arr;
    const ret = add(a, b);
    console.log("ret", ret);
    

    这玩意儿拿了德国 STF (主权技术基金)几十万欧元(大概),然后在 github 上面参与程度似乎也不是很高。我不是 js 程序员,所以想听听大家对这个东西怎么看。

    我自己的想法: 它的设计是,你需要类型检查你就标注,你不需要类型检查就不标注。这其实就兼顾了写代码的顺畅感和可靠性。但是是否真的所有函数需要手动标注类型,或者说手动标注类型的比例有多大,这是个问题。一些高阶函数我也不知道怎么标注类型。

    21 条回复    2024-01-24 16:12:04 +08:00
    CHTuring
        1
    CHTuring  
       316 天前
    问题是,为啥不在开发时就就避免错误或给出有效报错信息,甚至要手动标注。

    TS:你们是不是在找我...
    codehz
        2
    codehz  
       316 天前 via iPhone
    @CHTuring 看介绍实际上是支持 ts 的
    运行时检查还是不太一样的吧,不过说到底也只是给开发阶段用的,ts 好好写能避免第一方的类型问题,但项目不可避免的会引入第三方代码或一些难以在 ts 框架下描述的类型,用了 any 一类的逃生仓,就有可能出现运行时类型不符合预期的情况
    lisongeee
        3
    lisongeee  
       316 天前
    codehz
        4
    codehz  
       316 天前 via iPhone
    不过我觉得运行时检查类型,可能对一些复杂的类型处理不好,比如 ts 那边经常用的一些伪名义类型技巧引入的虚拟元素(实际对象中不存在,仅为了触发 ts 的名义类型模式)
    SingeeKing
        5
    SingeeKing  
       316 天前
    RN 其实就在努力做类似的事情,让 TypeScript 不仅仅是标注而是做到断言
    ufo5260987423
        6
    ufo5260987423  
    OP
       316 天前
    @SingeeKing 请问 RN 是什么?
    jones2000
        7
    jones2000  
       316 天前   ❤️ 3
    什么要定义死类型呢? js 变量本来就是可以是任何类型的, 为什么要框死它呢? 这个不是 js 的一大特色吗?
    ufo5260987423
        8
    ufo5260987423  
    OP
       316 天前
    @CHTuring 开发的时候标注类型,其实很多情况下是很复杂的一件事情。比如 https://docs.racket-lang.org/ts-guide/caveats.html 这里的一个案例:
    ```lisp
    (map cons '(a b c d) '(1 2 3 4))
    ```
    这个操作在 lisp 里面一般还挺正常的,但是 type-racket 强制要求类型标注以后,就必须这样写
    ```lisp
    (map (inst cons Symbol Integer) '(a b c d) '(1 2 3 4))
    ```
    编码流畅性很受影响。我不懂 js 和 typescript ,不过好像 ts 会编译为 js 执行?那难道不会出现类型标注方面的问题么?
    SingeeKing
        9
    SingeeKing  
       316 天前   ❤️ 1
    @SingeeKing React Native ,可以搜索下 React Native 的 Static Hermes
    ufo5260987423
        10
    ufo5260987423  
    OP
       316 天前
    @codehz 我不懂 ts 哈,能不能指路“伪名义类型技巧”是啥?
    ufo5260987423
        11
    ufo5260987423  
    OP
       316 天前
    @jones2000 技术方面的我就不讲了。德国 STF 的考虑是类型不安全造成技术方面的隐患。他们挺重视这个事儿的。
    jones2000
        12
    jones2000  
       316 天前
    @ufo5260987423 存在即合理。不从源头堵上( JavaScript 语言标准),基本没什么用。
    ufo5260987423
        13
    ufo5260987423  
    OP
       316 天前
    @jones2000 花钱给领导们买安心。德国领导也是领导,笑。
    libook
        14
    libook  
       316 天前 via Android
    有运行时强类型需求首先考虑强类型语言吧,后端可以用 go Java ,前端可以 webassembly 。
    JS 的设计目标之一就是类型灵活,加太多限制就显得用 JS 没啥必要了。这就好比买苹果电脑装 Windows 。
    fulvaz
        15
    fulvaz  
       316 天前
    依赖 jsdoc 注定只能是个 KPI 项目。如果你加班修 bug 的时候,刚好发现有一个第三方库能搞定问题,但是这个库没有没有 jsdoc ,阁下该如何应对?

    其次应用复杂度上去后,性能会凉凉,也就小型项目用一下 ----- 但是小型项目的复杂度还需要考虑类型安全?上 ts 都是浪费人力。
    ufo5260987423
        16
    ufo5260987423  
    OP
       316 天前
    @fulvaz #15 都用 js 了,考虑啥性能问题?
    fulvaz
        17
    fulvaz  
       315 天前
    @ufo5260987423 v8+jit 不慢了,快从上世纪回到现代世界
    ufo5260987423
        18
    ufo5260987423  
    OP
       315 天前
    @fulvaz #17 你说的“不慢了”是和谁比?有 benchmark 么?
    我说的“考虑啥性能问题”这句话很明显指的是:如果考虑性能问题用 c/c++。
    难道这个实际 js 已经比 c/c++快?
    应用复杂度上去后,性能会凉凉……从这句话将,你说的是大型 web 项目?大型 web 项目考虑性能,好像很多也是用 java 、go 之类的——所以你说的是 js 的 v8+jit 性能可以和 java 、go 比?这个我的确不知道,请给 benchmark 。

    我觉得你说话不动脑子,我上面讲的很多东西你完全不看。可能是一年能够批 50 万欧元给一个开源项目的组织,里面有很多不如你聪明的人吧。
    fulvaz
        19
    fulvaz  
       314 天前   ❤️ 1
    @ufo5260987423 巧了不是,我的工作恰好是给一个用 js 写的大型 web 应用做性能优化,大概是 office 那个量级的玩意。

    “如果考虑性能问题用 c/c++” 很明显不是所有情况都可以这么做,比如 vscode 团队当年想用 c++ 重写部分 CPU 密集场景的逻辑,最后发现通信成本的消耗很高,最后方案是基于 js 继续做优化。另外 google docs 也是 js ,只能说快的一批。

    这还不看啊,我都把工作经验给你输出了......
    fulvaz
        20
    fulvaz  
       314 天前
    前人已经给我们指明,js 虽然没 c++快,但也不算很慢。

    研发写得代码才是影响性能的关键,而不是语言,哥们别纠结了
    tedding
        21
    tedding  
       314 天前
    @fulvaz 深有同感 最近在优化一个四五年前的项目中的部分功能( 10s 打不开一个页面。。。就离谱
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1016 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 22ms · UTC 21:38 · PVG 05:38 · LAX 13:38 · JFK 16:38
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.