添加 uuid 和 random-uuid 函数

Question

ClojureScript 有 {{uuid}} 和 {{random-uuid}} 函数。这些函数在 ClojureScript 中很有用，我认为在 Clojure 中也有用，可以提高代码的可移植性。对此有何建议？

Answer 1

评论者：wilkerlucio

(链接： ~alexmiller) 我理解使它完全兼容会很好，但老实说，作为一个写了很多 CLJC 的用户，如果我们只有 uuid 和 random-uuid（尤其是后者），就可以解决我 99% 的 UUID 需要，我想对大多数人来说也是如此。我们不能先添加那些对 everyone using 都有把握的，然后把详细设计的 UUID 事情留在一个单独的条目上吗？

Comments

今天我自己遇到了这个问题。在 `.clj` 文件中键入了 `uuid`，希望像在 ClojureScript 中一样从字符串构造一个 UUID。导入 `java.util.UUID` 并调用 `UUID/fromString` 工作正常，但如果 `uuid` 是 `clojure.core` 函数那会更好。对于 `clojure.core` 中的 `random-uuid`，我也表示赞同，以便于移植性（而不是我们现在使用的 `UUID/randomUUID`）。

Answer 2

由 alexmiller 发布的评论

我认为这样做的主要原因是移植性。最好生成 java.util.UUID，这在 ClojureScript 中也会很合适吗？也就是说，用于创建和 使用 uuids 的同一代码是否可以在两个平台上运行？如果不能，那么这样做的理由可能并不充分。

Answer 3

由 [email protected] 发布的评论

最好生成 java.util.UUID，这在 ClojureScript 中也会很合适吗？

ClojureScript 定义了自己的 UUID 类型，因为 JavaScript 中没有。 https://github.com/clojure/clojurescript/blob/dd589037f242b4eaace113ffa28ab7b3791caf47/src/main/cljs/cljs/core.cljs#L10088-L10128。我不太确定你说的“合适”是什么意思。

也就是说，用于创建和使用 uuids 的同一代码能否在两个平台上运行？

CLJS UUID 不支持 Java UUID 的所有方法，但重要功能都有（等效性、从字符串创建、字符串输出），这将显著提高在使用 UUID 时的工作移植性。

Answer 4

由 bronsa 发布的评论

clojure 和 clojurescript 都有 uuid 标记字面量，这对于互操作性应该足够。

Answer 5

由 alexmiller 发布的评论

我了解这一点，只是想知道是否有任何在 uuid 上可以调用的函数需要在便携的等价物上，比如在 http://docs.oracle.com/javase/8/docs/api/java/util/UUID.html 中的东西。

Answer 6

评论者：[email protected]

这里的大部分额外方法都很有用，可以用来区分不同类型的UUID，或者从基于时间的UUID中获取信息。


clockSequence() - 基于时间的
compareTo(UUID val) - 不确定是否需要等价的功能？
boolean equals(Object obj) - 无需操作
static UUID fromString(String name) - 构造器
long getLeastSignificantBits() - 不确定这两个属性有多重要
long getMostSignificantBits()
int hashCode() - 无需操作
static UUID nameUUIDFromBytes(byte[] name) - 这个功能有用/重要吗？
long node() - 仅对基于时间的UUID有用
static UUID randomUUID() - 将实现此功能
long timestamp() - 基于时间的UUID
String toString() - 无需操作
int variant() - 用于区分不同类型的UUID
int version() - 用于区分不同版本的UUID



我可能看到了将基于时间的UUID包含在补丁中的理由，但我不确定它们是否足够常用以至于值得这样做，并且它们还需要放入CLJS等。

在Clojure代码中使用了其中一些方法
https://github.com/search?l=clojure&q=.getLeastSignificantBits&type=Code&utf8=✓
https://github.com/search?utf8=✓&q=%22.nameUUIDFromBytes%22+language%3Aclojure&type=Code&ref=searchresults

但少于直接构造器的一个因素约100倍
https://github.com/search?utf8=✓&q=java+util+UUID+language%3Aclojure&type=Code&ref=searchresults（这是一个有缺陷的搜索查询，但已是最好的结果）。

Answer 7

由 alexmiller 发布的评论

我的主要观点可能是：与其只考虑uuid/random-uuid函数，不如考虑这个问题：我们如何在Clojure/ClojureScript中添加可移植的UUID支持？这是一项更多的工作，但据我看来，这要更有价值。

因此，还需要考虑以下问题（其中一些已经存在，但可能还没有进行过可移植性的测试）
- 构造
- 打印 - 打印、pr、漂亮打印
- 读取
- 哈希码
- 转换为/从位
- 转换为/从字符串
- 提取组件

然后我认为考虑这部分是否应该包含在核心库中（在data.uuid等库中）是很值得的。

我认为最好是根据设计页面进行这项工作，而不是在这里（这项工单只是更大问题的一个小部分）。也许http://dev.clojure.org/pages/viewpage.action?pageId=950382可以提供一些指导。

Answer 8

参考: https://clojure.atlassian.net/browse/CLJ-1925 (由 [email protected] 报告)