This code generates a warning for overriding a deprecated nonEmpty method in IterableOnceOps. Does that mean I cannot define my own iterable with a nonEmpty method? I have to live with a deprecated, iterator-based nonEmpty method instead of relying on my own isEmpty?
That’s a strange view. The Iterable doc states: “Base trait for generic collections.” Even if an iterable doesn’t have to be a collection, many collections are iterable. How can they indicate that they are? Indeed, IterableOnce is the better trait for things that may not be collections, i.e., that can only be iterated once. What type should a collection, which can be iterated repeatedly, implement, if not Iterable?
Since IterableOps extends IterableOnceOps, I don’t think this is going to solve my nonEmpty problem. Also, I’m not implementing a generic collection but only a sequence of Char. I’m looking for a way to say “I have an iterator”, like java.lang.Iterable does. Maybe there isn’t such a type in Scala.
Overriding nonEmpty is still deprecated, but that’s because it is implemented as !isEmpty in IterableOnceOps.
If that’s really all you want, I think that’s more or less the definition of IterableOnce. But then of course almost all methods except iterator will be deprecated by design.
As I mentioned above the nonEmpty that you get through IterableOnceOps (which Iterable and IterableOps extend) actually has an efficient !isEmpty implementation. That method should actually be final and all those methods on IterableOnce should not exist. But that’s not the case because of some migration philosophy for people coming from Scala 2.12, from back when they thought they could still clean up the std library way before Scala 4.0.
I think if all I need is to say “I have an iterator”, I should simply implement an iterator method and forget about Iterable. In Java, expressing “I have an iterator” using the Iterable interface enables the foreach loop, but in Scala, there is not such benefit.
I also thought that, if I really need the Iterable type, I can get it using a lambda, i.e.:
val w = Word("foo")
val t: Iterable[Char] = () => w.iterator
but that doesn’t work. I have to write the more cumbersome:
val t: Iterable[Char] = new Iterable[Char] { def iterator = w.iterator }
Someone has to intervene with a collections “dad joke”, but that person won’t be me.
Thanks for the “user story”, as I just realized that my recent tweak to IterableOnceOps to “prefer knownSize to isEmpty” should actually include using knownSize from isEmpty.
For now, I will say, based on that PR experience, the best simple thing is:
object Test extends App {
val s = "hello, world"
val chars = new collection.AbstractIterable[Char] {
def iterator: Iterator[Char] = s.iterator
override def knownSize = s.knownSize // s.length
override def isEmpty = s.isEmpty // knownSize == 0 || super.isEmpty // push upstream
}
}
That ensures your trivial implementation is maximally trivial and free of mixin.
I’ll contribute that obvious [sic?] improvement to isEmpty.
SAM conversion was broken when they stripped all the parens from iterator.
You can restore them in a custom subclass, which I named LIterable because it lets you use your function literal for an Iterable. Let the puns begin.
There is a Scala 2 bug for which I just created a ticket: adding parens is allowed in Scala 3 but not Scala 2. I don’t recall if there is a reason.
As an additional PSA, the Scala 3 import syntax is supported under Scala 2 -Xsource:3, which I always use unless other conditions don’t permit.
As another PSA, missing backtick and hitting escape in this UI is unnerving.
import collection.AbstractIterable
abstract class LIterable[+A] extends AbstractIterable[A] {
def iterator(): Iterator[A]
}
object Test extends App {
val s = "hello, world"
val chars = new AbstractIterable[Char] {
def iterator: Iterator[Char] = s.iterator
override def knownSize = s.knownSize
}
import java.lang.{Iterable as JIterable}
import scala.jdk.CollectionConverters.*
val schars: LIterable[Char] = () => s.iterator
val jchars: JIterable[Char] = () => s.iterator.asJava
val easy = jchars.asScala
println(chars.partition('o'.==))
println(schars.partition('o'.==))
println(easy.partition('o'.==))
}
'o'.== is a tribute to Orion, the craft currently visiting the moon. That is a solar array sticking out.
Unrelated topic, but that’s something I was wondering while writing my example (and I ended up being inconsistent). In terms of uniform access principle, it doesn’t make sense to me. iterator must involve the construction of a fresh object and cannot possibly be a field. What’s the rationale for not having parentheses? Simply that x.iterator.find(...) looks better than x.iterator().find(...)? More generally, is there a document somewhere that describes a consistent principle/philosophy to follow?
(I’ve always disliked new Foo, but now it’s just Foo() without new, so I’m happy. I also struggle with methods like Future.get in Java, which may block a thread. And something like iterator is another situation where I find it hard to remain consistent.)
Thanks, I also enjoyed the link there to the ancient mailing list thread.
On the morning of the third day, Seth changed his mind and reversed his opinion. Luckily, by referential transparency, all he needed to do was seth.opinion.reverse.
It’s nice to see that Odersky was unwavering on this point throughout the decade. I can’t tell if he was overruled or ignored.
I’ve often wondered if I would understand today those old Tony Morris adages:
I think a placebo has a relative non-zero adverse impact compared to null.
I guess not. But if null means nullary as in f(), then instead of “parameterless” for f (as the Dotty docs have it), we can now say, “placebary” or perhaps “placatary” (alt for placatory). I still prefer Scala 2’s nullary, nilary, nelary, to indicate the length of paramss.head.
The current style guide describes its policy for method invocation rather than definition. That is, all methods could be defined with parens, but coder discipline would demand their omission when the method usage looks like a variable. (The compiler would supply invisible parens via “empty application”.)
Also interesting is the objection to infix alphabetic xs addOne item, which is not that it is hard to parse visually, but that it is side-effecting and therefore should have parens.
Resist the urge to omit parentheses simply to save two characters!
Especially if they are bad characters, in which case they are most likely beyond saving.