Como explicar a referência do método de conversão para Iterable no loop for-each em Java?

Java converte qualquer referência de método ou lambda que você vê em um tipo real: esse tipo deve ser o chamado tipo funcional, que é qualquer interface onde, se você retirar quaisquer métodos e java.lang.Objecttambém quaisquer métodos com uma defaultimplementação, deixa exatamente um método . Então essa é uma interface funcional; você pode marcá-lo @FunctionalInterface, mas isso é apenas documentação verificada pelo compilador: esse ato não o torna uma interface funcional; esse ato apenas diz ao compilador: Por favor, gere um erro do compilador se eu anotar algo que não seja uma interface funcional com ele.

O problema é que Iterable é uma interface funcional: é uma interface que define um método, com a assinatura: Dados zero argumentos, produza 1 Iterador.

E, ao que parece, lines::iterator também se ajusta a essa assinatura: esse é um método que não aceita argumentos e retorna um iterador.

Observe que lines::iteratornão invoca o método iterator() do que quer que linesseja. Em vez disso, codifica a ideia de fazer isso. O valor de lines::iteratoré 'a ideia de invocar o método iterator() em tudo o que linesexiste'. Qualquer que seja o código fornecido, 'este conceito' pode então optar por realmente seguir em frente e fazer isso. E então faça de novo. Ou nunca faça isso. Ou salve e faça amanhã, em outro tópico.

Isto é, se ele for compilado - esse é um método ref, portanto deve ser usado em um contexto onde um tipo funcional é necessário; você não pode simplesmente escrever Object o = lines::iterator;.

Dado o elenco, agora há um contexto. Então, tudo bem então. (Iterable<String>) lines::iteratoré java válido.

Ele ainda faz a principal diferença semântica entre Iterablee Iterator: Iterável é repetível: você pode 'recomeçar' - basta invocar o .iterator()método uma segunda vez, o que lhe dará um novo iterador que começa no início. Em contraste, um Iteratornão pode voltar atrás. Depois de invocar, next()você seguiu em frente. Não há prev()ou reset()ou goTo(0)ou qualquer outra coisa. Você pode invocar .iterator()isso Iterable<String>que criou mais de uma vez e o compilador não o impedirá de escrever esse código.

Exceto que isso não é realmente útil: então este é um hack , mas relativamente inócuo. Iterableas instâncias devem ser repetíveis, mas a documentação do Streammétodo iterator()é bastante clara de que não é repetível - depois de percorrer esse iterador, você não poderá fazê-lo novamente. O compilador não reclamará se você invocar .iterator()mais de uma vez, mas o tempo de execução sim - essa segunda chamada causará uma exceção. É por isso Stream que tem um iterator()método, mas não implementa Iterable<T>. Mesmo que isso fosse trivial - o compilador não impediria o Stream de fazer isso (já que todas as instâncias de Iterable devem ter um método: public Iterator<T> iterator(), que ..Stream<T>faz!. Nem todos os requisitos em uma API podem ser capturados pelo sistema de tipos e 'devem ser invocáveis ​​​​várias vezes, retornando um iterador novo e funcional posicionado no início do que quer que seja, sempre que você o chamar' é algo que os Iteráveis ​​​​devem fazer, mas isso não acontece e que o sistema de tipos não pode capturar.

Portanto, isso produz um Iterable quebrado . Portanto, deixá-lo escapar como parte de uma API pública é uma péssima ideia. No entanto, neste trecho, ele é usado imediatamente, então, presumivelmente, o código pode 'contornar' sua falha (a falha é: você não pode invocá- iterator()lo mais do que apenas uma vez). O código realmente deveria ter um comentário explicando que este é um iterável incompleto e, portanto, o código não deve permitir que ele escape, nem pode ser invocado iterator()nele mais de uma vez.