----- Mail original ----- > De: "Brian Goetz" <brian.go...@oracle.com> > À: "Michael Kuhlmann" <j...@fiolino.de>, "core-libs-dev" > <core-libs-dev@openjdk.java.net> > Envoyé: Mardi 17 Novembre 2020 20:44:17 > Objet: Re: 'Find' method for Iterable
> On 9/21/2020 4:08 AM, Michael Kuhlmann wrote: >> But after thinking about it, I'm now convinced that it would be a bad >> idea. Because it extends the scope of this small, tiny Iterable >> interface to something bigger which it shouldn't be. > > This response captures the essence of the problem. You may think you > are asking for "just one more method on Iterable", but really, what you > are asking for is to turn Iterable into something it is not. Iterable > exists not to be "smallest collection", but as the interface to the > foreach-loop. Yes, we could have chosen a different design center for > Iterable (Eclipse Collections did, see RichIterable), but we didn't. > Adding this method merely sends the signal that we want to extend > Iterable to be more than it is, which opens the floodgate to requests > (and eventually demands) for more methods. > >> I can ask about Iterable#forEach - is it there only because it was there to >> begin with? Would it have been a bad idea to add one if we had streams >> already? > > While you can make an argument that forEach is excessive, the fact that > you make this argument illustrates the essential problem with this > proposal. Your argument wrt forEach is "If that makes sense, then so > does find." If you pull on that string, then this method forms the > basis of tomorrow's assumption: "You have forEach and find, it is > unreasonable to not add <my pet method>". There is a good reason to have forEach, Iterable in the interface of things that can be iterated, and in Java, there are two ways to do an iteration, the internal iteration, where you ask the class to do the iteration for you using forEach and the external iterator, where you ask for an Iterator and use it to iterate outside of the class. In term of API design, it is push vs pull, using forEach, the element are is pushed to the Consumer while using an Iterator.next() allow you to pull the element. Usually, forEach() is faster but it takes a Consumer, so you are limited by the limitation of the lambda (you can not mutate the local variables of the enclosing scope). Using an Iterator is also more powerful because you can compose them. > > So, Iterable should stay simple. (The other arguments against it on > this thread, are also valid, but this is the most important one.) Yep. Rémi
