为什么 scala 集合没有任何人类可读的方法,如 .append、.push 等

发布于 2024-12-01 08:04:17 字数 107 浏览 1 评论 0原文

Scala 集合有一堆可读和几乎可读的运算符,例如 :++:,但为什么没有任何人类可读的同义词,例如 append

Scala collections have a bunch of readable and almost readable operators like :+ and +:, but why aren't there any human readable synonyms like append?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(5

海拔太高太耀眼 2024-12-08 08:04:17

Scala 中的所有可变集合都具有 BufferLike 特征,它定义了一个 append 方法。

不可变集合没有 BufferLike 特征,因此只定义其他方法,这些方法不会就地更改集合,而是生成一个新集合。

All mutable collections in Scala have the BufferLike trait and it defines an append method.

Immutable collections do not have the BufferLike trait and hence only define the other methods that do not change the collection in place but generate a new one.

一片旧的回忆 2024-12-08 08:04:17

符号方法名称允许与赋值操作 = 组合。

例如,如果您有一个创建新集合的方法 ++ ,则可以自动使用 ++= 将新集合分配给某个变量:

var array = Array(1,2,3)
array ++= Array(4,5,6)
// array is now Array(1,2,3,4,5,6)

这是不可能的没有符号方法名称。

Symbolic method names allow the combination with the assignment operation =.

For instance, if you have a method ++ which creates a new collection, you can automatically use ++= to assign the new collection to some variable:

var array = Array(1,2,3)
array ++= Array(4,5,6)
// array is now Array(1,2,3,4,5,6)

This is not possible without symbolic method names.

听风吹 2024-12-08 08:04:17

事实上,它们经常有一些人类可读的同义词:

  • foldLeft 相当于 /:
  • foldRight 相当于 :\

其余的是加法运算符,它们非常易于人类阅读:

  • ++ 相当于 java addAll
  • :+ 是append
  • +: 是前置

的位置分号表示接收者实例。

最后,一些奇怪的运算符是其他函数式编程语言的遗产。例如列表构建 (SML) 或参与者消息传递 (erlang)。

In fact they often some human-readable synonyms:

  • foldLeft is equivalent to /:
  • foldRight is equivalent to :\

The remaining ones are addition operators, which are quite human readable as they are:

  • ++ is equivalent to java addAll
  • :+ is append
  • +: is prepend

The position of the semi-colon indicates the receiver instance.

Finally, some weird operators are legacies of other functional programming languages. Such as list construction (SML) or actor messaging (erlang).

狠疯拽 2024-12-08 08:04:17

它与其他语言有什么不同吗?

让我们以Java为例。 int 上的 +-*/ 的人类可读版本是什么?或者,我们以 String 为例:+ 的人类可读版本是什么?请注意,concat 不是一回事——它不接受非String 参数。

也许您对此感到困扰,因为在 Java 中——与 C++ 不同——要么专门使用非字母运算符,要么使用字母运算符——除了 String+

Is it any different than any other language?

Let's take Java. What's the human readable version of +, -, * and / on int? Or, let's take String: what's the human readable version of +? Note that concat is not the same thing -- it doesn't accept non-String parameters.

Perhaps you are bothered by it because in Java -- unlike, say, C++ -- either things use exclusively non-alphabetic operators, or alphabetic operators -- with the exception of String's +.

九局 2024-12-08 08:04:17

Scala 标准库并不是对 Java 友好的。相反,提供了适配器来在 Java 和 Scala 集合之间进行转换。

尝试提供 Java 友好的 API 不仅会限制标识符的选择(或要求提供别名),还会限制泛型和函数类型的使用方式。需要进行更多的测试来验证设计。

关于同一主题,我记得关于 2.8 集合是否应该实现 java.util.Iterable 的一些争论。

http://scala-programming-language.1934581.n4.nabble.com/How-to-set-the-scale-for-scala-BigDecimal-s-method-td1948885.html

http://www.scala-lang.org/node/2177

The Scala standard library does not set out to be Java friendly. Instead, adapters are provided to convert between Java and Scala collections.

Attempting to provide a Java friendly API would not only constrain the choice of identifiers (or mandate that aliases should be provided), but also limit the way that generics and function types were used. Substantially more testing would be required to validate the design.

On the same topic, I remember some debate as to whether the 2.8 collections should implement java.util.Iterable.

http://scala-programming-language.1934581.n4.nabble.com/How-to-set-the-scale-for-scala-BigDecimal-s-method-td1948885.html

http://www.scala-lang.org/node/2177

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文