Pourquoi ne pas Aller de permettre imbriqués les déclarations de fonction (les fonctions à l'intérieur des fonctions)?

Edit: Si il n'était pas clair ce que je demande: quels sont les problèmes qui sont atténués en ne permettant pas imbriquées les déclarations de fonction?

Lambdas comme prévu:

func main() {
    inc := func(x int) int { return x+1; }
}

Toutefois, la déclaration suivante à l'intérieur d'une déclaration n'est pas permis:

func main() {
    func inc(x int) int { return x+1; }
}

Pour quelle raison sont des fonctions imbriquées pas permis?

  • hmm je ne sais pas si vous vouliez faire ce func main() { func (x int) int { return x+1; }(3) }
  • mais c'est une lambda ainsi, n'est-ce pas? Je ne comprends pas votre commentaire...
  • quelles fonctionnalités permettant le deuxième exemple de la syntaxe permettre, qui n'est pas pris en charge par le premier cas?
  • c'est une expression lambda, je ne pense pas que vous pouvez déclarer une fonction à l'intérieur d'une autre fonction comme JS. Je dirais donc que votre meilleur ajustement est d'utiliser les lambdas.
  • Une possibilité serait de mettre en œuvre le moyen le JavaScript n', essentiellement de l'affectation d'une fonction à une variable est très différente de celle de la déclaration d'une fonction en raison de l'écoulement de contrôle des effets sur les variables, tandis que les fonctions en JavaScript ne sont pas affectés. Cela signifie que vous pourriez appeler inc() dans le deuxième exemple, avant la déclaration. Mais! Je suis à la recherche pour des raisons, je ne connais pas trop y Aller, mais je voudrais savoir ce que la logique qui sous-tend cette règle a été.
  • oui, je sais, je ne suis pas vraiment de la programmation rendez-vous dès maintenant, et si j'étais lambdas me conviendrait très bien. Je me demandais pourquoi les concepteurs ont choisi de faire de cette façon et pas l'autre, c'est tout.
  • Eh bien, si il ya une chose que je ne faisais pas de JS est l'étendue mess 🙂 Aussi garder à l'esprit que Go est compilé, les fonctions qui ne sont pas des lambdas ne sont pas créés au moment de l'exécution. en JS tout ce qui est créé lors de l'exécution.
  • Je ne vois pas comment le fait de changer le système de déclaration serait de faire des choses différentes, je suis assez d'accord avec Not_a_Golfer ici. J'ai entendu plusieurs fois de la Go dev team, ils ne veulent pas de multiples syntaxe de déclaration de tout ce qui cause de graves dégâts dans le long terme.
  • la chose drôle est que Rob Pike a fait une drôle de commentaire sur la façon dont JS/Ruby/Python devs ont presque pas de notion de portée. twitter.com/rob_pike/status/402853302464831488
  • oups je faisais allusion à ce tweet -> twitter.com/rob_pike/status/402853390973026305
  • pour être juste, Python est assez stricte sur les étendues la plupart du temps, vous ne pouvez même pas l'assigner à une variable globale dans une fonction sans la global mot-clé, et il est rarement utilisé. Le seul cas qui causent de la confusion sont statiques vs les membres de l'instance.
  • double possible de N'Allez avoir des expressions lambda ou quelque chose de similaire?
  • Pourquoi les downvotes? Je l'ai fait essayer à la recherche mais tous, je suis venu avec était un Google Groupes thread demander la même chose mais pas de réponses utiles. Si il n'était pas clair, j'ai édité maintenant. Je ne vois pas comment il serait "pas utile" - il pourrait être intéressant de problèmes qui pourraient découler de ces fonctions imbriquées...
  • Aussi quels sont exactement la portée de problèmes que les gens sont en train de parler? Peut-on avoir un résumé qui montre ce que les Go ne différemment et comment est-ce mieux? Je suis à la recherche moi-même, mais si vous avez eu une belle source de qui allait l'aider.
  • Trouvé quelque chose sur le JavaScript de délimitation de l'étendue des questions: dailyjs.com/2012/07/23/js101-scope.
  • Je voudrais juste ajouter que la question proposée comme un doublon ne demande pas la même chose!
  • vieux post, mais pour le dossier: "cela signifie Que l'on pourrait appeler inc() dans le deuxième exemple, avant la déclaration" > ceci est spécifique à Javascript et généralement appelé déclaration de fonction de levage. Golang (comme la plupart des autres langages de programmation) ne pas hisser les déclarations de fonction. Je pense que c'est une bonne chose (moins de confusion), mais de toute façon, c'est le choix qui a été fait.
  • Un problème à résoudre est récursive des fonctions imbriquées, voir github.com/golang/go/issues/226

InformationsquelleAutor corazza | 2014-02-22
  1. 45

    Je pense qu'il y a 3 raisons pour lesquelles cette fonctionnalité évidente n'est pas autorisé

    1. Il ne ferait que compliquer le compilateur légèrement. Au moment où le compilateur sait toutes les fonctions sont au plus haut niveau.
    2. Il ferait une nouvelle classe de programmeur d'erreur que vous pourriez refactoriser quelque chose et accidentellement nid certaines fonctions.
    3. Ayant une autre syntaxe pour les fonctions et les fermetures est une bonne chose. Faire une fermeture est potentiellement plus cher que de faire une fonction de sorte que vous devriez savoir vous le faites.

    Ceux là sont mes opinions bien - je n'ai pas vu un officiel de la déclaration de la langue concepteurs.

    • Pascal (au moins, c'est Delphi incarnation) a eu la bonne et simple: les fonctions imbriquées se comportent comme des réguliers, mais aussi avoir accès à des variables dans leur fonction englobante de la portée. Je ne pense pas qu'elles sont difficiles à mettre en œuvre. D'autre part, après avoir écrit beaucoup de code Delphi je ne suis pas sûr que j'ai cruellement besoin de fonctions imbriquées: de temps en temps ils se sentent chouette mais ils ont tendance à souffler la fonction englobante rendant difficilement lisible. Aussi l'accès aux arguments de leurs parents peut rendre le programme difficile à lire, car ces variables sont accessibles de manière implicite (pas passés comme paramètres formels).
    • les fonctions locales sont grands comme un intermédiaire refactoring étape sur votre chemin à l'extrait de méthodes. En c#, ils ont fait de ces plus de valeur une fois ils ont introduit statique locale des fonctions qui ne sont pas autorisés à capturer les variables de fonction englobante de sorte que vous êtes obligés de passer n'importe quoi comme paramètre. Statique locale funcitons faire, point 3, un non-problème. Le Point 2 est aussi un problème, de mon point de vue.
    InformationsquelleAutor Nick Craig-Wood
  2. 23

    Sûr qu'ils sont. Vous avez juste à les affecter à une variable:

    func main() {
    inc := func(x int) int { return x+1; }
}
    InformationsquelleAutor Matt Williamson
  3. 21

    Foire aux Questions (FAQ)

    Pourquoi n'Allez pas fonction de X?

    Chaque langue contient de nouvelles fonctions et omet de quelqu'un favori
    fonctionnalité. Go a été conçu avec un oeil sur la félicité de la programmation, de la vitesse
    de la compilation, de l'orthogonalité des concepts, et la nécessité de soutenir
    des fonctionnalités telles que la simultanéité et la collecte des ordures. Votre favori
    fonctionnalité peut être manquant, car il ne convient pas, car il affecte
    vitesse de compilation ou à la clarté de la conception, ou parce qu'il ferait l'
    fondamental du système de modèle trop difficile.

    Si ça te dérange tant que Go est manquant fonction de X, veuillez nous pardonner et
    enquêter sur les fonctionnalités qui Vont n'avoir. Vous pourriez trouver qu'ils
    compenser de manière intéressante, le manque de X.

    Ce qui justifierait la complexité et les coûts de l'ajout de fonctions imbriquées? Que dois-yau veulent faire que vous ne pouvez pas faire sans les fonctions imbriquées? Et cetera.

    • bien fait, monsieur, bonne réponse.
    • Pour être honnête, je ne pense pas que quiconque fait preuve d'une particulière complexité qu'en permettant à des fonctions imbriquées serait la cause. De Plus, si je suis d'accord avec la cité de la philosophie, je ne suis pas sûr que c'est raisonnable de se référer à fonctions imbriquées comme une "fonctionnalité," d'autant que la référence à leur omission comme une caractéristique. Connaissez-vous des complications qu'en permettant à des fonctions imbriquées permettrait? Je suis en supposant qu'ils venais sucre syntaxique pour les lambdas (je ne peux pas penser à tout autre comportement raisonnable).
    • Depuis go est compilé, la seule façon de le faire autant que je sache, va créer une autre syntaxe pour la définition des lambdas. Et je ne vois vraiment pas un cas d'utilisation pour que. vous ne pouvez pas avoir une fonction statique à l'intérieur d'une fonction statique créée en temps réel - et si nous n'avons pas d'entrer le code spécifique chemin qui définit la fonction?
    • Il suffit de passer lambda interface{} et le type d'affirmer. Par exemple. f_lambda := lambda(func()rval{}) ou quel que soit le prototype serait. La touche func decl syntaxe ne supporte pas cela, mais la langue tout à fait ne.
    InformationsquelleAutor peterSO
  4. 11

    Voici une façon de mettre en œuvre des fonctions imbriquées et fonctions au sein de fonctions imbriquées

    package main

    import "fmt"

    func main() {
        nested := func() {
            fmt.Println("I am nested")

            deeplyNested := func() {
                fmt.Println("I am deeply nested")
            }

            deeplyNested()
        }

        nested()
    }
    InformationsquelleAutor Koala3
  5. 0

    Fonctions imbriquées sont autorisés à Aller. Vous avez juste besoin de les affecter à des variables locales au sein de la fonction externe, et de les appeler à l'aide de ces variables.

    Exemple:

    func outerFunction(iterations int, s1, s2 string) int {
    someState := 0
    innerFunction := func(param string) int {
        //Could have another nested function here!
        totalLength := 0
        //Note that the iterations parameter is available
        //in the inner function (closure)
        for i := 0; i < iterations; i++) {
            totalLength += len(param)
        }
        return totalLength
    }
    //Now we can call innerFunction() freely
    someState = innerFunction(s1)
    someState += innerFunction(s2)
    return someState
}
myVar := outerFunction(100, "blah", "meh")

    Les fonctions internes sont souvent pratique pour les locaux goroutines:

    func outerFunction(...) {
    innerFunction := func(...) {
        ...
    }
    go innerFunction(...)
}
    • Fermeture à aller se distingue par certains aspects de la plaine de la fonction. Par exemple, vous ne pouvez pas appeler la fermeture de manière récursive.
    • Vous pouvez appeler récursivement si vous le déclarer avant de le définir.
    InformationsquelleAutor vthorsteinsson
  6. -2

    Vous avez juste à appeler immédiatement en ajoutant () à la fin.

    func main() {
    func inc(x int) int { return x+1; }()
}

    Edit: ne peut pas avoir le nom de la fonction...donc c'est juste une lambda func appelé tout de suite:

    func main() {
    func(x int) int { return x+1; }()
}
    • Heu ... qui ne sont pas conformes à ce que l'on pourrait attendre d'une définition de fonction
    • Ah, j'ai raté le mot "déclaration" quand j'ai lu la question. Mon mauvais.
    • Aussi, j'ai foiré la syntaxe aussi. Nécessaires pour supprimer le nom de la fonction. Donc, en gros, c'est une fonction lambda qui est appelée immédiatement.
    InformationsquelleAutor Nick