2024 年 Clojure 状态调查! 中分享您的想法。

欢迎!请参阅 关于 页面以了解更多有关此内容的信息。

0 投票
ClojureScript
此 ClojureScript 变更
https://github.com/clojure/clojurescript/commit/bcf60ce194e5292fbc5c4b2d89dfc5a7b886b94c
追踪了这个 Clojure 变更
https://github.com/clojure/clojure/commit/20f67081b7654e44e960defb1e4e491c3a0c2c8b

结果之一是,{{int?}} 由非固定精度的 {{goog.math.Integer}} 满足。
此外,它创建了这样一种情况:可能存在满足 {{int?}} 但不满足 {{integer?}} 或 {{number?}} 的值。(注意,这也影响像 {{pos-int?}} 这样的东西。)

我建议两种替代方法来解决这个问题,我们可以进行辩论

方案 A:简单地将 {{goog.math}} 项从 {{int?}} 及其类似项中删除。

方案 B:让 {{goog.math.Long}} 值满足 {{number?}},{{integer?}} 和 {{int?}},并让 {{goog.math.Integer}} 值满足 {{number?}} 和 {{integer?}}。

在任何情况下,都应该更新文档字符串。

我将附上两个具体的补丁以供考虑/辩论。

3 答案

0 投票
_ 评论由: favila_ 提供

CLJS 中各种数值断言的目标应该是什么?

目标是与 CLJ 中这些断言的含义一致吗?如果是这样,那么
{{number?}} 对 typeof-number 或 goog.math.Integer 或 goog.math.Long 为真
{{integer?}} 对 goog.math.isInt/Number.isInteger 或 goog.math.Integer 或 goog.math.Long 为真
{{int?}} 对 goog.math.isInt/Number.isInteger 或 goog.math.Long 为真

目标是与平台原生的某个概念一致吗?如果是这样,那么
{{number?}} 对 typeof-number 或 goog.math.Integer 或 goog.math.Long 为真
{{integer?}} 对 goog.math.isInt/Number.isInteger 或 goog.math.Integer 或 goog.math.Long 为真
{{int?}} 只有在 goog.math.isInt 为真时才为真

目的是进行 can-I-do-arithmetic-with-this 类型的检查吗?如果是这样,那么
{{number?}} 只有在 typeof-number 为真时才为真
{{integer?}} 对 goog.math.isInt(也许甚至是 Number.isSafeInteger)为真
{{int?}} 与 integer? 相同


In Java/CLJ 这些三个目标与彼此更加一致。任何数字标识符都可以用于 clj 计算(所以最宽的检查 {{number?}} 也可以用于计算检查),而 {{int?}} 与宿主的原始整数值类型(与对象类型)相对应。

CLJS 缺乏数字塔,所以更有趣。
目前,在CLJS中,{{number?}}看起来被设计为一个谓词,用于测试是否可以进行算术运算,因此它只允许js的type-of===number。{{integer?}}也是一个算术检查,但需要的是非分数数(有趣的是,仍然允许不安全的整数,即超出Number.MAX_SAFE_INTEGER的范围,在那里正常的整数算术无法进行——也许它应该只允许安全的整数)。 {{int?}}不在乎算术,但它仍然很有用,可以看看一个值是否可能是数值标识符(例如,通过transit接收到的记录id);但这与CLJ的int?所关心的完全不同。

0 投票
_由 mfikes 发表的评论_

附带的A和B补丁探索了两种方法。

补丁A可以按照现有的样子应用。

另一方面,补丁B似乎有多个与是否符合{{number?}}以及该符号能否参与算术运算或用于其他当前使用数字的地方相关的后果。我怀疑我们可能能够让这一切工作,但我们将会牺牲很多性能。

作为具体的一个例子:这是一个有效的程序,应该返回{{true}}吗?


(zero? goog.math.Integer/ZERO)
0 投票
...