Comment implémenter idiomatiquement des générateurs Go à l'aide de Goroutines et de canaux ?

La manière idiomatique d'implémenter des générateurs avec Yield dans Go pour les fonctions récursives

Dans Go, l'implémentation de générateurs utilisant le mot-clé Yield n'est pas directement prise en charge par la langue. Cependant, une approche idiomatique consiste à simuler cette fonctionnalité à l’aide de goroutines et de canaux. Voici un examen plus approfondi de vos questions :

1. Manière idiomatique d'implémenter des générateurs

La manière la plus idiomatique d'implémenter des générateurs avec le même comportement que le rendement est d'avoir une fonction basée sur une goroutine qui envoie des valeurs dans un canal. Cette goroutine devrait fermer le canal lorsque toutes les valeurs ont été générées. Voici un exemple :

package main

import (
    "fmt"
    "time"
)

// Generate integers in a goroutine.
func generateIntegers(numbers []int, c chan<- int) {
    defer close(c)

    for _, n := range numbers {
        c <- n
        time.Sleep(time.Second) // Simulate delay for clarity
    }
}

func main() {
    numbers := []int{1, 2, 3, 4, 5}
    c := make(chan int)

    go generateIntegers(numbers, c)

    // Consume the generated values.
    for v := range c {
        fmt.Println(v)
    }
}

2. Responsabilité de la fermeture du canal

Idiomatiquement, la fonction génératrice (celle qui produit les valeurs) devrait être responsable de la fermeture du canal. Cela garantit que le canal est fermé lorsque toutes les valeurs ont été générées, permettant au consommateur de savoir quand arrêter de recevoir des valeurs.

3. Modification du code

La modification que vous proposez, pour rendre l'appelant responsable de la fermeture du canal, qu'il ait besoin ou non de toutes les permutations, est également une approche idiomatique. Cependant, il est important d'utiliser le report pour garantir que le canal est fermé même si une erreur se produit.

// Modify the caller code:

package main

import (
    "./lib"
    "fmt"
)

var (
    fruits  = []string{"apple", "banana", "cherry", "durian"}
    banned = "durian"
)

func main() {
    channel := lib.PermutateWithChannel(fruits)
    defer close(channel)

    for myFruits := range channel {
        fmt.Println(myFruits)
        if myFruits[0] == banned {
            // Close the channel when the banned fruit is encountered.
            // Since we're using defer, this will happen even if an error occurs.
            break
        }
    }
}

4. Effets secondaires négatifs potentiels de la fermeture d'un canal après que l'appelant l'a fermé

Dans votre exemple, l'appelant ferme le canal une fois que le générateur a envoyé toutes les permutations. Cependant, la goroutine exécutant le code du générateur peut toujours essayer d'envoyer vers le canal fermé. Cela ne provoque aucun effet secondaire négatif observable, car la goroutine va simplement paniquer. Cependant, il est toujours recommandé de fermer les chaînes uniquement lorsqu'elles ne sont plus nécessaires pour éviter tout comportement inattendu et garantir une gestion efficace des ressources.

5. Renvoi d'un canal de réception uniquement

Il est possible de renvoyer un canal de réception uniquement à partir de la fonction générateur. Cela empêche l'appelant de fermer le canal, garantissant ainsi que seul le générateur en a la responsabilité. Voici comment procéder :

// Generator function returns a receive-only channel.
func generateIntegers(numbers []int) <-chan int {
    c := make(chan int)
    go func() {
        defer close(c)

        for _, n := range numbers {
            c <- n
            time.Sleep(time.Second) // Simulate delay for clarity
        }
    }()

    return c
}

Cela garantit que l'appelant ne peut pas fermer le canal, évitant ainsi les problèmes décrits à la question 4.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!