性能与安全如何兼得proposal-operator-overloading 设计目标深度解析含拒绝 monkey-patching 的理由【免费下载链接】proposal-operator-overloading项目地址: https://gitcode.com/gh_mirrors/pr/proposal-operator-overloading当你在 JavaScript 里写下a b时有没有想过为什么Decimal(1) Decimal(2)不能直接等于Decimal(3)这正是proposal-operator-overloadingJavaScript 运算符重载提案想要回答的问题。作为一个面向 TC39 的正式提案它试图在不牺牲性能、不破坏安全的前提下为 JS 引入可自定义的运算符行为。本文将从它的设计目标出发深度解析表达力、可预测性、高性能三者如何兼得并重点说明为什么它坚决拒绝 monkey-patching——这可能是整个提案中最有争议、也最值得学习的设计决策。什么是 proposal-operator-overloadingJavaScript 长期以来只有Number和BigInt两种真正的数值类型。日常开发中我们还需要十进制、有理数、复数、向量、矩阵……在其它语言里这些类型可以优雅地使用 - * /直接运算而在 JS 中只能靠a.mul(b).add(c)这样的方法链硬撑。proposal-operator-overloading 就是为解决这个问题而来它允许开发者定义自己的类型并让这些类型像内置类型一样支持运算符。例如引入一个Decimal类后你可以直接写with operators from Decimal; Decimal(1) Decimal(2) // Decimal(3)值得一提的是该提案目前状态为Withdrawn已撤回它更像一次认真的语言实验——用足够具体的方案帮 TC39 委员会判断这条路到底该不该走。完整的规格草案见 PROTOSPEC.md。三大设计目标表达力、可预测性与性能 提案在 README.md 中明确写下了三大设计目标这也是理解整个方案的一把钥匙。表达力让库作者拥有原生的语法运算符重载的价值在于赋能更丰富的库。提案给出了四个典型案例数值类型Decimal、有理数、复数等参考 README.md 中的 decimal 示例矩阵/向量计算new Vector([1,2,3]) new Vector([4,5,6])直接返回新向量方程 DSLTensorFlow.js 中的a * x ** 3 b * x * x c * x d可以写成自然的数学表达式而不是a.mul(x.pow(3)).add(...)的方法链CSS 单位运算Css.em(3) CSS.px(2)这类直观写法表达力的关键约束是只允许重载内置运算符不允许自定义新运算符。因为自定义运算符如 Haskell 的%abc%会带来解析复杂度和标点过载的可读性灾难。可预测性已有代码的行为不可被悄悄改变这一条直指核心问题运算符在已有对象上的含义不能被覆盖或 monkey-patch。无论是内置类型还是其它库定义的对象都不允许第三方代码篡改其运算符行为。提案用了一个很巧妙的机制来保证这一点with operators from词法声明。它要求使用者显式声明启用哪些类的运算符重载作用域限定在代码块内。未经声明的类运算时直接抛TypeError。也就是说运算符重载是一种静态、不可变的对象属性而不是可以随时被改写的全局状态。高效可实现性不能拖慢不用它的代码性能是语言特性落地的生命线。提案明确要求不影响不使用运算符重载的代码包括同一模块内其它路径对使用了重载的代码要**利于内联缓存inline caching**和JIT 优化支持单态monomorphic和多态polymorphic两种场景后文会单独展开这套性能方案的细节。为什么拒绝 monkey-patching安全设计深度解析 你可能想问不让我 monkey-patch那我做测试 mock 怎么办——这是提案在 Q/A 部分正面回答过的问题。monkey-patching 的风险如果允许任何代码改写某个类型的运算符定义那么所有依赖该类型的代码都会变得不可靠。想象一下你引入了一个第三方库它悄悄改写了String或某个核心类的行为整个项目的运算结果都可能瞬间失真且极难排查。这与 JavaScript 开发者习惯的稳定性背道而驰。三种替代方案提案给出了更安全的替代路径独立 mock 类创建另一个支持运算符重载的类行为与目标类一致或与它交互自定义 hooks在运算符定义中预留自己的接口供测试注入配合with operators from声明本身就是一个能力凭证capability只有持有该类的代码才能触发其运算符更关键的是提案通过内部槽[[OperatorSet]]实现了静态绑定——对象一旦创建它的运算符集合就不可变更配合Object.preventExtensions进一步加固。这套静态不可变性正是性能优化的基础下一节会看到。性能方案揭秘从内部槽到内联缓存 ⚡性能与安全在这份提案里其实是同一枚硬币的两面。详细机制见 PROTOSPEC.md核心思路如下第一步内部槽 实例类型快速判定每个支持重载的对象都有一个[[OperatorSet]]内部槽指向一个不可变的 Operator Set 记录。在 V8 这类引擎中带重载的对象可以被赋予独立的 instance_type就像 BigInt 那样引擎只需一次极廉价的类型检查就能判断这个对象是否参与运算符重载——不参与就直接走原路径零开销。第二步双操作数统一调度与 Python/Ruby 的先查左操作数、再查右操作数不同提案采用基于两个操作数的统一调度通过OperatorCounter给每个 Operator Set 编号调度时比较两个操作数的编号再查对应的定义表。这种方式没有 Python 那种左操作数优先的偏袒也为 JIT 生成稳定的调度代码创造了条件。第三步内联缓存与位掩码检查在 JIT 生成的代码里只需检查两个操作数的 map 是否一致即可命中同一个运算符实现无需失效逻辑——因为重载定义不可变map 相同则行为必相同。而with operators from的启用检查被实现为一个词法作用域的位掩码bitmask内联缓存通过比对位掩码对象身份来降低检查开销。这些实现思路在 PROTOSPEC.md 的 Implementation notes 一节有详细阐述。与其它语言对比proposal-operator-overloading 的取舍 项目里的 LANGCOMP.md 是一份非常扎实的跨语言对比文档覆盖了 Python、Ruby、C、Swift、Haskell、Rust、Matlab 等主流方案。几个关键结论只重载内置运算符这是最主流、最稳妥的设计多数语言Python、C#、Kotlin都这么做统一调度最接近 Matlab提案的调度方式在主流语言里独树一帜值得谨慎推进拒绝原型链多重分派虽然 Slate 等语言采用过但实现与优化过于复杂收益不明确这套对比也解释了提案为什么敢在表达力上做减法——限制越多性能与安全的空间越大。动手体验Babel 插件与运行时 shim ️虽然提案已撤回但项目给出了可运行的原型实现分为两个 npm 包src/transform/Babel 转换插件littledan/plugin-transform-operator-overloading把块级作用域内的运算符调用重写为运行时函数核心逻辑见 plugin.jssrc/shim/运行时支持littledan/operator-overloading-shim实现Operators工厂、_binary/_unary调度与withOperatorsFrom启用逻辑核心逻辑见 shim.js想亲自跑一遍可以这样安装npm install --save-dev littledan/plugin-transform-operator-overloading npm install --save-prod littledan/operator-overloading-shim然后在.babelrc中启用插件即可。安装使用细节见 transform/README.md。需要注意原型 shim 出于简化目的并没有做到 100% 防 monkey-patch错误检查也稍弱——这恰恰反衬出正式规范里那些安全约束的价值。如果你想在本地跑测试src/shim/下的 shim.spec.js 覆盖了加减乘除、比较运算、字符串拼接等大量场景。结语一份虽撤回但珍贵的设计样本 proposal-operator-overloading 用一句话概括它的设计哲学就是用可预测的约束换取可实现的性能与可靠的安全。拒绝 monkey-patching 不是保守而是为了让运算符重载在生态中长期稳定地存在。无论这份提案最终是否以其它形式回归 JavaScript它关于表达力—可预测性—性能三角平衡的思考都值得每一位语言爱好者与库作者细细品读。【免费下载链接】proposal-operator-overloading项目地址: https://gitcode.com/gh_mirrors/pr/proposal-operator-overloading创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 性能与安全如何兼得？proposal-operator-overloading 设计目标深度解析（含拒绝 monkey-patching 的理由）
性能与安全如何兼得proposal-operator-overloading 设计目标深度解析含拒绝 monkey-patching 的理由【免费下载链接】proposal-operator-overloading项目地址: https://gitcode.com/gh_mirrors/pr/proposal-operator-overloading当你在 JavaScript 里写下a b时有没有想过为什么Decimal(1) Decimal(2)不能直接等于Decimal(3)这正是proposal-operator-overloadingJavaScript 运算符重载提案想要回答的问题。作为一个面向 TC39 的正式提案它试图在不牺牲性能、不破坏安全的前提下为 JS 引入可自定义的运算符行为。本文将从它的设计目标出发深度解析表达力、可预测性、高性能三者如何兼得并重点说明为什么它坚决拒绝 monkey-patching——这可能是整个提案中最有争议、也最值得学习的设计决策。什么是 proposal-operator-overloadingJavaScript 长期以来只有Number和BigInt两种真正的数值类型。日常开发中我们还需要十进制、有理数、复数、向量、矩阵……在其它语言里这些类型可以优雅地使用 - * /直接运算而在 JS 中只能靠a.mul(b).add(c)这样的方法链硬撑。proposal-operator-overloading 就是为解决这个问题而来它允许开发者定义自己的类型并让这些类型像内置类型一样支持运算符。例如引入一个Decimal类后你可以直接写with operators from Decimal; Decimal(1) Decimal(2) // Decimal(3)值得一提的是该提案目前状态为Withdrawn已撤回它更像一次认真的语言实验——用足够具体的方案帮 TC39 委员会判断这条路到底该不该走。完整的规格草案见 PROTOSPEC.md。三大设计目标表达力、可预测性与性能 提案在 README.md 中明确写下了三大设计目标这也是理解整个方案的一把钥匙。表达力让库作者拥有原生的语法运算符重载的价值在于赋能更丰富的库。提案给出了四个典型案例数值类型Decimal、有理数、复数等参考 README.md 中的 decimal 示例矩阵/向量计算new Vector([1,2,3]) new Vector([4,5,6])直接返回新向量方程 DSLTensorFlow.js 中的a * x ** 3 b * x * x c * x d可以写成自然的数学表达式而不是a.mul(x.pow(3)).add(...)的方法链CSS 单位运算Css.em(3) CSS.px(2)这类直观写法表达力的关键约束是只允许重载内置运算符不允许自定义新运算符。因为自定义运算符如 Haskell 的%abc%会带来解析复杂度和标点过载的可读性灾难。可预测性已有代码的行为不可被悄悄改变这一条直指核心问题运算符在已有对象上的含义不能被覆盖或 monkey-patch。无论是内置类型还是其它库定义的对象都不允许第三方代码篡改其运算符行为。提案用了一个很巧妙的机制来保证这一点with operators from词法声明。它要求使用者显式声明启用哪些类的运算符重载作用域限定在代码块内。未经声明的类运算时直接抛TypeError。也就是说运算符重载是一种静态、不可变的对象属性而不是可以随时被改写的全局状态。高效可实现性不能拖慢不用它的代码性能是语言特性落地的生命线。提案明确要求不影响不使用运算符重载的代码包括同一模块内其它路径对使用了重载的代码要**利于内联缓存inline caching**和JIT 优化支持单态monomorphic和多态polymorphic两种场景后文会单独展开这套性能方案的细节。为什么拒绝 monkey-patching安全设计深度解析 你可能想问不让我 monkey-patch那我做测试 mock 怎么办——这是提案在 Q/A 部分正面回答过的问题。monkey-patching 的风险如果允许任何代码改写某个类型的运算符定义那么所有依赖该类型的代码都会变得不可靠。想象一下你引入了一个第三方库它悄悄改写了String或某个核心类的行为整个项目的运算结果都可能瞬间失真且极难排查。这与 JavaScript 开发者习惯的稳定性背道而驰。三种替代方案提案给出了更安全的替代路径独立 mock 类创建另一个支持运算符重载的类行为与目标类一致或与它交互自定义 hooks在运算符定义中预留自己的接口供测试注入配合with operators from声明本身就是一个能力凭证capability只有持有该类的代码才能触发其运算符更关键的是提案通过内部槽[[OperatorSet]]实现了静态绑定——对象一旦创建它的运算符集合就不可变更配合Object.preventExtensions进一步加固。这套静态不可变性正是性能优化的基础下一节会看到。性能方案揭秘从内部槽到内联缓存 ⚡性能与安全在这份提案里其实是同一枚硬币的两面。详细机制见 PROTOSPEC.md核心思路如下第一步内部槽 实例类型快速判定每个支持重载的对象都有一个[[OperatorSet]]内部槽指向一个不可变的 Operator Set 记录。在 V8 这类引擎中带重载的对象可以被赋予独立的 instance_type就像 BigInt 那样引擎只需一次极廉价的类型检查就能判断这个对象是否参与运算符重载——不参与就直接走原路径零开销。第二步双操作数统一调度与 Python/Ruby 的先查左操作数、再查右操作数不同提案采用基于两个操作数的统一调度通过OperatorCounter给每个 Operator Set 编号调度时比较两个操作数的编号再查对应的定义表。这种方式没有 Python 那种左操作数优先的偏袒也为 JIT 生成稳定的调度代码创造了条件。第三步内联缓存与位掩码检查在 JIT 生成的代码里只需检查两个操作数的 map 是否一致即可命中同一个运算符实现无需失效逻辑——因为重载定义不可变map 相同则行为必相同。而with operators from的启用检查被实现为一个词法作用域的位掩码bitmask内联缓存通过比对位掩码对象身份来降低检查开销。这些实现思路在 PROTOSPEC.md 的 Implementation notes 一节有详细阐述。与其它语言对比proposal-operator-overloading 的取舍 项目里的 LANGCOMP.md 是一份非常扎实的跨语言对比文档覆盖了 Python、Ruby、C、Swift、Haskell、Rust、Matlab 等主流方案。几个关键结论只重载内置运算符这是最主流、最稳妥的设计多数语言Python、C#、Kotlin都这么做统一调度最接近 Matlab提案的调度方式在主流语言里独树一帜值得谨慎推进拒绝原型链多重分派虽然 Slate 等语言采用过但实现与优化过于复杂收益不明确这套对比也解释了提案为什么敢在表达力上做减法——限制越多性能与安全的空间越大。动手体验Babel 插件与运行时 shim ️虽然提案已撤回但项目给出了可运行的原型实现分为两个 npm 包src/transform/Babel 转换插件littledan/plugin-transform-operator-overloading把块级作用域内的运算符调用重写为运行时函数核心逻辑见 plugin.jssrc/shim/运行时支持littledan/operator-overloading-shim实现Operators工厂、_binary/_unary调度与withOperatorsFrom启用逻辑核心逻辑见 shim.js想亲自跑一遍可以这样安装npm install --save-dev littledan/plugin-transform-operator-overloading npm install --save-prod littledan/operator-overloading-shim然后在.babelrc中启用插件即可。安装使用细节见 transform/README.md。需要注意原型 shim 出于简化目的并没有做到 100% 防 monkey-patch错误检查也稍弱——这恰恰反衬出正式规范里那些安全约束的价值。如果你想在本地跑测试src/shim/下的 shim.spec.js 覆盖了加减乘除、比较运算、字符串拼接等大量场景。结语一份虽撤回但珍贵的设计样本 proposal-operator-overloading 用一句话概括它的设计哲学就是用可预测的约束换取可实现的性能与可靠的安全。拒绝 monkey-patching 不是保守而是为了让运算符重载在生态中长期稳定地存在。无论这份提案最终是否以其它形式回归 JavaScript它关于表达力—可预测性—性能三角平衡的思考都值得每一位语言爱好者与库作者细细品读。【免费下载链接】proposal-operator-overloading项目地址: https://gitcode.com/gh_mirrors/pr/proposal-operator-overloading创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考