为什么所有基本不可变集合都是最终的或密封在 scala 中?

发布于 2024-12-28 07:01:04 字数 427 浏览 1 评论 0原文

我在 Scala 中编写了一个用于对可迭代对象进行排序的特征,并且创建一个可以将其混合在一起的类所花费的时间几乎与编写该特征所花费的时间一样长。为什么设计决定不允许用户编写如下内容:

new List[Int] with SuperAwesomeTrait[Int]?

现在,如果我想这样做,我需要做一些奇怪的黑客,

class StupidList extends LinearSeq {
  val inner = List()
  /* reimplement list methods by calling into inner */
} 

然后

new StupidList[Int] with SuperAwesomeTrait[Int].

I wrote a trait for sorting iterables in Scala, and it took almost as long to make a class that I could mix it in with as it took to write the trait. Why was the design decision made to disallow users from writing things like:

new List[Int] with SuperAwesomeTrait[Int]?

Now if I want to do this, I need to do some weird hack like,

class StupidList extends LinearSeq {
  val inner = List()
  /* reimplement list methods by calling into inner */
} 

and then

new StupidList[Int] with SuperAwesomeTrait[Int].

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

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

发布评论

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

评论(1

可爱咩 2025-01-04 07:01:04

因为如果我写,

someList match {
  case Cons(head, tail) => whatever
  case Nil => somethingElse
}

我不希望我的逻辑被一个新的、意想不到的子类破坏。

我怀疑您正在尝试使用子类化来解决问题,而使用隐式可以更好地解决该问题。

Because if I write

someList match {
  case Cons(head, tail) => whatever
  case Nil => somethingElse
}

I don't want my logic broken by a new, unexpected subclass.

I suspect you're trying to solve a problem using subclassing that would be better solved with implicits.

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