Godot: Private Variablen oder Funktionen in GDScript

Am nächsten kommt es für Variablen, setget zu verwenden, um zu einer Funktion zu führen, die entweder nichts tut oder eine Warnung ausgibt. Aber nein, keine echten privaten Variablen oder Funktionen.

@YeldhamDev Leider ist setget hilfreich, aber wenn Sie kein öffentliches Eigentum sehen möchten, gibt es keine Möglichkeit, dies zu tun. Das ist schlecht, @reduz was denkst du?

Auch in Python ist dies nicht möglich: Selbst der doppelt führende Unterstrich hindert Sie nicht daran, auf Variablen zuzugreifen und sie zu ändern. In Python verwenden Sie stattdessen Konventionen: ein führender Unterstrich, um anzuzeigen, dass eine Variable privat ist, ALL_CAPS, um anzuzeigen, dass etwas eine Konstante ist ... sie sind immer noch von überall zugänglich, aber in der Praxis ist dies kein Problem.

@NathanLovato Vielleicht sollte sich GDScript in diesem Fall von Python unterscheiden?

@Chaosus Sie sollten Argumente

Private Variablen dienen dazu, Daten zu kapseln und eine Kopplung mit anderen Klassen zu verhindern - sie verhindern, dass andere Klassen auf diese Variablen zugreifen. Wenn Sie erst gar nicht darauf zugreifen, ist das Problem ebenfalls gelöst.

In beiden Fällen - mit dem Schlüsselwort private oder mit einer Konvention - müssen Sie lernen, wann und wie Sie Variablen privat machen, wann und wie Sie darauf zugreifen können. Sie müssen lernen, Ihre Klassen so zu gestalten, dass Sie später die Interna ändern können, ohne ihre Schnittstelle zu beschädigen und umgekehrt. Ich denke, das ist Ihre größte Problemquelle, wenn es um die Codearchitektur geht.

In Bezug auf Python funktioniert es für Millionen von Python-Entwicklern. Es gibt einen Mechanismus, um Variablen "privat" zu machen, der den direkten Zugriff verhindert, und es ist einfach: Schreiben Sie zwei führende Unterstriche anstelle von einem. Aber ich habe noch nicht gesehen, dass jemand es benutzt. Es war bis vor kurzem auch nicht in JS verfügbar. Es gibt wahrscheinlich noch andere Sprachen wie diese.

Ich sage nicht, dass es nicht in GDscript sein sollte - es macht mir wirklich nichts aus, wenn andere Leute eine gute Verwendung für das Feature haben. Ich bin einfach nicht überzeugt, dass es so nützlich ist. ZB könnte Godot einfach keine Variablen mit einem führenden _ oder zwei in der Autovervollständigung auflisten (obwohl es _function_name als Konvention für virtuelle Funktionen verwendet)?

Ich möchte nur keine internen Methoden mit Intellisense in GDScript sehen und es eher wie C# und andere statisch typisierte Sprachen machen

Ja, ich stimme zu, es ist schwierig zu implementieren und erfordert ein neues Keyword, zu viel Aufwand für ein sehr kleines Ergebnis
Die Lösung mit dem Präfix "__" löst das Problem teilweise, danke (ich habe noch nie mit Python gearbeitet, daher ist es etwas Neues für mich).

Ich weiß, dass dies bereits geschlossen und archiviert ist (nicht sicher, ob dafür ein anderes Problem geöffnet werden sollte), aber Zugriffsmodifikatoren sind ein ziemlich wichtiges Feature in jeder Programmiersprache. Wenn ich ein neues Node-Addon für Godot erstellen möchte und mein neuer Knoten interne Zustandsvariablen hat, die außerhalb des Nodes nicht geändert werden sollen, steht dem nichts im Wege. Ich verstehe, dass Sie führende Unterstriche verwenden können, um diese Funktion nachzuahmen, aber es verhindert immer noch nicht den Zugriff, der der gesamte Punkt der Zugriffsmodifizierer ist. Meiner Meinung nach ist dies eine ziemlich große Sache, da es keine Möglichkeit gibt, die Art und Weise zu kontrollieren, wie andere mit Ihren Objekten interagieren.

Ja, ich stimme @dylmeadows zu, es wäre auf diese Weise nützlich

Ich bin definitiv auch für private Funktionen und Variablen.

1. Ja, wir haben eine Konvention für private mit einem _ vor einem Methodennamen, ABER die gleiche Konvention wird für virtuelle Funktionen verwendet. Wenn ich also einen Unterstrich sehe, könnte dies entweder bedeuten: "Berühre diese Funktion auf keinen Fall!" oder "überschreiben Sie diese Funktion!". Das ist ehrlich gesagt höllisch gefährlich.

2. Wenn ich alleine oder in einem sehr kleinen Team an einem kleinen Projekt arbeite, fällt mir das nicht so ins Gewicht, weil ich weiß, welche Funktionen verwendet werden sollen und welche nur für den internen Gebrauch bestimmt sind.
   Aber mit wachsenden Teams wird dies immer schwieriger. Die Leute arbeiten mit Klassen, die sie nicht die ganze Zeit selbst geschrieben haben, und da ich eine Person bin, die viele kleine interne Funktionen schreibt, damit die Dinge funktionieren, möchte ich wirklich in der Lage sein, zu verhindern, dass Leute diese Funktionen aufrufen, denn wenn sie es verwenden Diese können zu unbeabsichtigtem Verhalten und Fehlern führen und es kostet Zeit, diese Dinge zu beheben, sobald Fehler gemacht wurden. Und trotz einer gemeinsamen Konvention werden diese Dinge in einem größeren Team geschehen, weil sie schließlich von außen aufrufbar sind.

3. Zu guter Letzt; automatische Vervollständigung. Ich bin jemand, der dies oft nutzt, um zu lernen, was eine Klasse tun kann.
   Ich habe nur das '.' am Ende und sehen Sie, welche Funktionen auftauchen. Wenn etwas nützlich klingt, benutze ich es.
   Es wäre viel sauberer, wenn es nicht mit all den Funktionen überladen wäre, die sowieso nicht aufgerufen werden sollen. Außerdem weiß ich immer noch nicht, ob diese _name-Funktionen privat oder virtuell sind.

Außerdem können private Variablen sogar in einem persönlichen Projekt nützlich sein. Es gibt manchmal Zeiträume, in denen ich nicht an dem Spiel arbeiten kann, an dem ich arbeite, also vergesse ich, was einige meiner Funktionen tun. Oder ich vergesse, welche ich verwenden sollte und welche nicht.

Private Variablen wären toll damit! Es würde sicherstellen, dass außerhalb eines Nodes nicht auf eine Variable oder Funktion zugegriffen werden kann, und wenn ich zu einem Projekt zurückkomme, könnte ich erraten, wie man eine Variable verwendet und muss nicht meinen gesamten Code erneut vollständig durchlesen.

Ich unterstütze auch das, was Byteron und Dylmeadows gesagt haben. Sie haben ihre Beiträge nur gut genug geschrieben und genau das gesagt, was ich dachte. Wollte nur meine zwei Cent hinzufügen.

Ich werde wieder öffnen, da mehrere Benutzer interessiert sind und dies diskutieren möchten. Es ist noch nicht geplant, aber wir können diskutieren und sehen, ob es ein starkes Interesse an der Community gibt.

Python ist nicht die beste Sprache, die als ideal erwähnt wird.
Es wurde festgestellt, dass Godot sehr objektorientiert ist. Jedes Skript ist auch ein Objekt. Eines der Hauptprinzipien der objektorientierten Programmierung ist die Kapselung. wenn ich von außen etwas unberührtes haben möchte, dann wahrscheinlich aus den besten gründen.

Ich persönlich habe noch nie eine Zeit erlebt, in der ich unbedingt verhindern _ (oder _internal_ oder ähnlich) voran.

Ich würde nichts gegen ein Schlüsselwort (oder ähnliches) einwenden, das die Variable/Funktion einfach vor der automatischen Vervollständigung verbirgt. Ich glaube einfach nicht, dass es notwendig ist, den Zugriff vollständig zu verhindern.

Einerseits ist es besser zu warnen, nicht zu verbieten. Auf der anderen Seite werden private Felder und Methoden jedoch in der Regel viele Male verwendet. Und lange Variablennamen (zB _internal_variable ) sind etwas nervig.
In jedem Fall zwingt Sie das Vorhandensein des Schlüsselworts private nicht, es zu verwenden.

Private Member der Klasse in so etwas wie Konstanten. Ebenso können wir den Variablennamen in GROSSEN BUCHSTABEN schreiben und vereinbaren, dass wir seinen Wert nicht ändern. Aber das tun wir nicht, oder? Das heißt, private Variablen sind eine Kreuzung zwischen gewöhnlichen Variablen und Konstanten. Warum nicht ein spezielles Schlüsselwort für diesen Fall eingeben?

Ja, wir haben eine Konvention für private mit einem _ vor einem Methodennamen, ABER die gleiche Konvention wird für virtuelle Funktionen verwendet. Wenn ich also einen Unterstrich sehe, könnte dies entweder bedeuten: "Berühre diese Funktion auf keinen Fall!" oder "überschreiben Sie diese Funktion!". Das ist ehrlich gesagt höllisch gefährlich.

Das ist das größte Problem, das ich hier sehe. Anstelle des Schlüsselworts private könnten wir vielleicht ein Schlüsselwort virtual ? Einige virtuelle Methoden erscheinen bereits in der Autovervollständigung, wenn Sie "func" schreiben, daher könnte ein Schlüsselwort zur expliziten Unterscheidung zwischen virtuellen Funktionen, die Sie überschreiben sollen, und privaten Funktionen, die nicht in der Autovervollständigung erscheinen sollen, ausreichen. Der Vorteil des Schlüsselworts virtual besteht darin, dass Sie es seltener verwenden als private , sodass es weniger geschrieben wird.

Ich würde mich freuen, auch private Kursteilnehmer aufzunehmen. Es gibt einen Grund, warum dies in anderen Sprachen existiert. Andere Verbraucher/Teammitglieder (oder sogar Sie selbst) müssen nicht wissen, wie jede Klasse funktioniert. Tatsächlich sollten sie vielleicht nicht einmal die Möglichkeit haben, mit Funktionen herumzualbern, die sowieso intern sein sollen.

Ich verstehe, dass der führende Unterstrich "angeben" sollte, dass es sich um ein privates Mitglied handelt, aber in der Praxis kümmert es niemanden, ob eine Änderung die Aufgabe erledigt. Dies ist besonders schmerzhaft, wenn Sie einen Teil davon als Plugin verwenden möchten und jeder einfach ändern kann, was er möchte. Ich möchte die volle Kontrolle über den Zustand jedes von mir erstellten Objekts/Skripts haben. Objekte zu haben, die jeden Aspekt ihres Zustands ändern können, wann immer jemand dies möchte, macht die Erstellung von Code, den andere konsumieren können, mehr als irritierend.

Außerdem wäre es toll, die Liste der "verfügbaren" Variablen/Funktionen aufzuräumen.

Kann ich dem Entwicklerteam dann eine Empfehlung aussprechen, wenn ich all das bedenke? Ändern Sie die Reihenfolge der Autocomplete-Liste. Alle var oder func, die nicht mit einem Buchstaben oder einer Zahl beginnen, erscheinen am __Bottom__ der Autovervollständigungsliste. Dann musst du so ziemlich _ eingeben, um das Element zu sehen¿ Außerdem wäre es schön, wenn wir andere nicht-mathematische oder logische Symbole in Namen verwenden könnten? Ich habe es noch nicht ausprobiert, aber wären €Display oder ¥Print akzeptable Funktionsnamen? Usw.

Außerdem wäre es schön, wenn wir andere nicht-mathematische oder logische Symbole in Namen verwenden könnten? Ich habe es noch nicht ausprobiert, aber wären €Display oder ¥Print akzeptable Funktionsnamen? Usw.

Siehe https://github.com/godotengine/godot/issues/24785.

Nachdem ich damit herumgebastelt hatte, kam ich zu dem Schluss, dass, wenn Sie einen Setter definieren, der nichts tut, selbst wenn Sie versuchen, denselben Variablen in einem anderen Skript einen neuen Wert zuzuweisen und ihn zu drucken, der ursprüngliche Wert ist gedruckt. Es ist nicht wirklich privat, aber ich denke, es ist nahe genug...

bedeutet, dass es keinen Hinweis darauf gibt, dass die Variable, die öffentlich zu sein scheint und die Sie gerade geändert haben, nicht geändert wurde?
Viel Spaß beim Debuggen von Code, der diese Methode ausgiebig verwendet.

Anstelle eines leeren Setters können Sie auch einen Fehler drucken.

Ich weiß immer noch, dass ich etwas getan habe, was ich nicht hätte tun sollen, wenn ich das Programm starte und diese Codezeile tatsächlich erreicht habe. Es scheint immer noch öffentlich zu sein, während Code geschrieben wird, und es erfordert immer noch mehrere Codezeilen, um eine einzelne private Variable einzurichten.
Ein private vor diese Variable zu setzen ist viel kürzer, erfordert keine zusätzlichen Codezeilen und würde mich daran hindern, fälschlicherweise direkt bei der Eingabe darauf zuzugreifen.

GDScript fühlt sich für mich ziemlich C++-artig an, obwohl es eine dynamische Sprache ist. Wenn ich vom Schreiben von Code in C++ zu GDScript wechsle, vermisse ich diese Zugriffsmodifikatoren. Davon abgesehen fehlt GDScript tatsächlich die volle Unterstützung für OOP.

Ich habe dieses Problem nur überflogen, aber es wäre schön, Funktionen und Variablen zumindest vor der automatischen Vervollständigung ausblenden zu können, wenn ihren Namen ein Unterstrich vorangestellt ist. Ich denke, das Hauptproblem dabei ist die Feststellung, ob es sich um eine virtuelle Funktion handelt und daher wahrscheinlich unabhängig davon erscheinen sollte

Der Unterstrich wird auch für virtuelle Funktionen verwendet, und es gibt sicherlich Fälle, in denen virtuelle Funktionen auch öffentlich sein sollen.

Vielleicht verbergen Sie Funktionen mit Unterstrich-Präfix nur vor anderen Knoten/Objekten, aber zeigen Sie sie für Aufrufe auf self/base an.

Mein Vorschlag wäre, einen einfachen Unterstrich für virtuelle Funktionen und einen doppelten führenden Unterstrich für "private" Funktionen zu verwenden. Auf diese Weise können wir sie vor der Autovervollständigung verbergen, ohne die virtuellen Funktionen zu beeinträchtigen.

Die Verwendung von Unterstrichen zum Ausblenden einer Variablen ist schlecht, da Sie beim Ändern des Zugriffs-_Attributs_ der Variablen ihren _Namen_ ändern müssen. Tatsächlich sind variable und _variable unterschiedliche Namen.
Dies ist auch wie ein Punkt in UNIX-Dateinamen: eine ziemlich umstrittene Entscheidung.

Hier ist meine Meinung

• Präfix mit "__" für private Funktionen
• Funktionen mit "__" erscheinen nicht in der Autovervollständigung
• "private func x()" ist syntaktischer Zucker für "func __x()"

Das Obige unterbricht jeden Code, der eine Variable mit dem Präfix "__" enthält. Aber abgesehen davon denke ich, dass dieses System ideal wäre.

Die bisherigen Funktionen von GDScript sind Python/JS sehr ähnlich, und diese beiden Sprachen haben aus gutem Grund keine privaten Variablen und Funktionen - dies ist eine komplette Antithese zu ihrer Designphilosophie. Sie haben die Freiheit, und diese Freiheit ist wichtig, denn sie macht das Programmieren einfach. Sie opfern die Kapselung, aber das ist ihre Philosophie. Echte Kapselung ist bereits ohne Typprüfung gebrochen [Es sei denn, Sie überprüfen alle Typen selbst, was Sie wahrscheinlich nicht tun werden]. Wenn sie also keine strikte Typisierung implementieren, fühlen sich private Variablen falsch an. Im Gradienten von OOP kommt die strikte Typisierung vor privaten Variablen. Es gibt viele Sprachen mit strikter Typisierung, aber keine privaten Variablen, aber ich kenne keine Sprachen mit privaten Variablen und keiner strikten Typisierung. Dies wieder, aus gutem Grund. Darüber hinaus bietet Ihnen JS sogar Zugriff auf den gesamten Vererbungsbaum und lässt Sie auch diese Aspekte ändern. Sie können die Klasse, von der ein Objekt erbt, während der Laufzeit mit jedem Codestück ändern, das Ihr Objekt enthält! Das passiert natürlich nicht, zeigt aber die Designphilosophie.

Also meiner Meinung nach würden echte private Variablen die Sprache drastisch behindern. Wie auch immer, ich denke, Pythons System macht es gut, Sie haben __, mit dem Sie auf die privaten Variablen zugreifen können, aber es macht deutlich, dass Sie mit etwas Internem herumspielen, und dennoch schränkt es Sie nicht sinnvoll ein. Jeder, der eine echte OOP-Designphilosophie möchte, kann einfach nie "__" verwenden oder es im Codierungsstil seines Unternehmens oder seines Projekts verwenden. Vielleicht wäre eine Option, um es als Fehler zu markieren, nett. Ich meine, im Allgemeinen passen Duck-Typing und private Variablen nicht wirklich zusammen. Zumindest vermasseln Sie den Namespace total, denn was nun, obj.set("hi", 5) funktioniert nicht, wenn "hi" privat ist? Aber es funktioniert, wenn "hi" nicht existiert? Das macht nicht viel Sinn... Also, ein sehr starkes Nein, Privates zu erzwingen, völlig unzugänglich zu sein, egal was Sie tun, das ist meine Stimme. Sehr starkes Ja, damit private Variablen so existieren, wie Python es derzeit tut. Tbh, ich bin mir immer noch nicht sicher, wie ich das Duck-Typing-Problem mit privaten Variablen lösen soll, selbst wenn der Wunsch bestand, wirklich und unzugängliche private Variablen zu haben. Ich denke, Sie blockieren einfach obj.set und lassen es einen Fehler ausgeben. Jetzt muss obj.set anscheinend einen booleschen Wert zurückgeben, was seltsam ist. Ein is_private-Anruf? Dass Sie vor jeder Verwendung von obj.set aufrufen müssen? idk

[Oh mein Gott wirklich durch, können wir eine tatsächliche Fehlererkennung bekommen, wir sprechen über private Variablen, aber ab jetzt wird das Spiel, wenn Sie einen Fehler in gdscript haben, ihn einfach ignorieren (facepalm). Vielleicht mache ich es falsch, aber wenn mein Code etwas Illegales tut, scheint gdscript nur null von der Funktion zurückzugeben, was es so schwer macht, JS aufzuspüren, JS war jemals so schlecht und JS ist ein Durcheinander von einer Sprache. Ich weiß, dass das Abstürzen des Spiels zu viel sein könnte, aber ich muss immer nur meine Codebasis binär durchsuchen, indem ich print-Anweisungen einfüge, bis ich zwei aufeinanderfolgende print-Anweisungen finde, bei denen erstere gedruckt wird und letztere nicht, nur um herauszufinden, wo der Code kaputt gegangen ist. JS/Python sind in diesem Sinne überraschend viel strenger, obwohl sie in allem anderen frei sind.]

Ich schlage vor, eine konsistente Projektorganisation zu finden, um das Problem zu minimieren. Sie können den Wurzelknoten einer Szene als Schnittstelle verwenden, um die Szene von außen zu steuern und ein untergeordnetes Skript als Backend.

Alternativ können Sie nur Methoden verwenden, Variablen und Signale exportieren und niemals von außen auf die einfachen Variablen zugreifen. Das ist eine einfache Konvention und GDScript kann seine Einfachheit beibehalten.

Auch in Python ist dies nicht möglich: Selbst der doppelt führende Unterstrich hindert Sie nicht daran, auf Variablen zuzugreifen und sie zu ändern. In Python verwenden Sie stattdessen Konventionen: ein führender Unterstrich, um anzuzeigen, dass eine Variable privat ist, ALL_CAPS, um anzuzeigen, dass etwas eine Konstante ist ... sie sind immer noch von überall zugänglich, aber in der Praxis ist dies kein Problem.

Ich möchte nur sagen, dass es möglich ist, das Attribut _private_ in Python zu haben.

Zitat (https://www.python.org/dev/peps/pep-0008/):

__double_leading_underscore: ruft bei der Benennung eines Klassenattributs die Namensverkleinerung auf (innerhalb der Klasse FooBar wird __boo zu _FooBar__boo; siehe unten).

__double_leading_and_trailing_underscore__: "magische" Objekte oder Attribute, die in benutzergesteuerten Namensräumen leben. ZB __init__, __import__ oder __file__. Niemals solche Namen erfinden; nur wie dokumentiert verwenden

Wenn Sie auf diesen Link klicken und STRG+F "privat" verwenden, erhalten Sie

Den Begriff "privat" verwenden wir hier nicht, da in Python kein Attribut wirklich privat ist (ohne generell unnötigen Arbeitsaufwand).

Variablen mit doppeltem Unterstrich oder einfachem Unterstrich verhalten sich wie normale Variablen, es handelt sich lediglich um eine Konvention, die darauf hinweist, dass sie nicht verwendet werden sollten und sich beim Aktualisieren einer Bibliothek ändern können, da sie intern sind. Da Python-Sprachen wie GDScript Objekte so behandeln, als wären sie nur Wörterbücher, wäre es im Allgemeinen umständlich, private Variablen zu erzwingen und sie den Namensraum verbrauchen zu lassen.

Wenn Sie auf diesen Link klicken und STRG+F "privat" verwenden, erhalten Sie

Den Begriff "privat" verwenden wir hier nicht, da in Python kein Attribut wirklich privat ist (ohne generell unnötigen Arbeitsaufwand).

Variablen mit doppeltem Unterstrich oder einfachem Unterstrich verhalten sich wie normale Variablen, es handelt sich lediglich um eine Konvention, die darauf hinweist, dass sie nicht verwendet werden sollten und sich beim Aktualisieren einer Bibliothek ändern können, da sie intern sind. Da Python-Sprachen wie GDScript Objekte so behandeln, als wären sie nur Wörterbücher, wäre es im Allgemeinen umständlich, private Variablen zu erzwingen und sie den Namensraum verbrauchen zu lassen.

Ich stimme zu, sie nennen es nicht _private_ Attribut. Lassen Sie mich jedoch beschreiben, wie es funktioniert:

# defining class Employee
class Employee:
    def __init__(self, name, salary):
        self.name = name
        self.__salary = salary

>>> emp = Employee("Bill", 10000)
>>> emp.__salary
# AttributeError: 'employee' object has no attribute '__salary'

Es wird also kein _private_ Attribut genannt, aber es verhält sich fast so.
Es wäre toll, ein fast privates Attribut in GDScript zu haben, wie es in Python existiert.

Oh ja, da stimme ich dir voll und ganz zu. Python gibt Ihnen einfach syntaktischen Zucker für die Verwendung von ._Employee__salary. Ich persönlich mag die Art und Weise, wie Python es macht, nicht und ich denke, es kann in Godot stark verbessert werden, wie ich in meinem Kommentar erwähnt habe.

class Employee:
      var name # normal
      private var salary # Syntactic sugar for var _salary

Das ist sauberer, weil _Employee__salary eine hässliche Möglichkeit ist, den Variablennamen zu verbergen, und ein privates Schlüsselwort macht es wie normales OOP. Noch besser, dies blockiert die Möglichkeit, eine öffentliche Variable Gehalt und eine private Variable _salary zu haben, was hässlich wäre und wünschenswerterweise ein Syntaxfehler sein sollte, genau wie es in Java der Fall ist. Dies liegt daran, dass beide als "var-Gehalt" und "privat-var-Gehalt" deklariert würden, ein klarer Konflikt. Eine andere Möglichkeit wäre "Um auf die private Variable einer anderen Klasse C mit Member m zuzugreifen, müssen Sie einen Unterstrich wie in C._m verwenden". Wir könnten dann einen Fehler machen, eine Variable zu deklarieren, die mit einem Unterstrich beginnt, dh privat die einzige Möglichkeit zu machen, sie zu deklarieren, damit klar ist, was getan wird.

Ich denke, der einzige Grund, warum Python die weniger als wünschenswerte Situation hat, ist, dass es oben keine Deklarationen für die Variablen gibt, Sie erstellen einfach die Klassenvariablen in einem der Funktionskörper. GDScript scheint Deklarationen im Klassenrumpf zu erfordern, was einen leichten Übergang in Java-ähnliche private Deklarationen ermöglicht.

Ich mag es nicht, Schlüsselwörter zu verwenden, die als Syntaxzucker fungieren, es sei denn, sie sparen viel Tipparbeit. Wenn Sie hier private eingeben, werden Sie tatsächlich mehr Zeichen schreiben, was es zu einer Anti-Kurzbefehle macht :slightly_smiling_face:

Und wie sieht es mit Methoden aus? Mehrere virtuelle Methoden beginnen mit einem Unterstrich, sodass wir sie nicht mit einem einzelnen Unterstrich als privat markieren können. Wir könnten jedoch zwei Unterstriche verwenden, um Konflikte auf Kosten der Länge zu vermeiden. Ich mag auch die Idee, Python-Konventionen zu befolgen, wenn es sinnvoll ist – das "Dunder" ist in dieser Sprache seit einiger Zeit beliebt.

Ich glaube nicht, dass es als Abkürzung angesehen werden soll, sondern dass Sie außerhalb der Klasse "_" verwenden, um auf private Variablen zuzugreifen. Die Syntax Zucker wäre, wie sie implementiert wird. Im Wesentlichen identisch mit Python. Aber wie ja, es ist wahr, im Fall von Python spart der Syntaxzucker eine Menge Tipparbeit, aber das liegt nur daran, dass er zu etwas dummem langem Alias ​​wird. Aliasing in etwas Kürzeres ist einfach besser, also einen kürzeren Alias ​​zu haben und dann diesen Syntax-Zucker nicht zu verwenden, weil der Alias ​​zu kurz ist, läuft nur darauf hinaus, ob wir private Variablen überhaupt unterstützen sollten oder nicht; Wir müssen das nicht, wir können den Benutzern einfach Unterstriche voranstellen oder ihre eigene Konvention auswählen. Es ist nur für Java- und C++-orientierte Leute, die lieber "private var myvariable" schreiben würden, anstatt "_myvariable" einfach als privat zu nehmen, was sich seltsam anfühlt, wenn man aus einer OOP-Welt kommt, auch wenn beide genau das erreichen gleiche Sache. Doppelter Unterstrich würde ziemlich gut zu Pythons Syntax passen, also bin ich auch dafür bereit, besonders wenn _ mit anderen Sachen kollidiert

Ich hätte viel lieber ein Schlüsselwort, das das Verhalten außerhalb dessen definiert, was nur als Stilkonventionen fehlinterpretiert werden kann. private bekommt meine Stimme.

Feuer in die Diskussion einbringen: Die Python-Styling-Konvention für "private" Mitglieder besteht darin, einen Unterstrich vor dem Namen hinzuzufügen, der _bereits_ von gdscript für einen anderen Zweck in gängigen Ereignismethoden wie _ready() , _input und _physics_process , um nur einige zu nennen. Sollen die privat sein? Wie würde das Hinzufügen eines privaten Keywords mit diesen Methoden interagieren? Müssen auch andere Keywords wie protected implementiert werden?

Auf jeden Fall bin ich dafür, restriktive Direktiven _by Design_ durchzusetzen, anstatt nur den Benutzern die Definition von Konventionen zu überlassen. Aber ich bin mir nicht so sicher, ob private Klassenmitglieder angesichts der Komplexität der Implementierung die beabsichtigte Verbesserung bewirken würden. Die gesamte API müsste auch überdacht werden, stelle ich mir vor. Die ganze Sprache hätte ein ganz anderes Paradigma.

Ja, das hat schon jemand bemerkt. (Siehe Calinous Antwort) Doppelte Unterstreichung wäre der richtige Weg. Genauso wie Python.

Mein 2c. In Python hindert nichts jemanden daran, auf Klassenmitglieder zuzugreifen, die mit _ , und mit etwas internem Wissen auch mit __ .

Es geht darum, Absicht zu zeigen. Die Philosophie ist, dass wir alle erwachsen sind, wir können die Entscheidung treffen, ob wir wirklich auf vermeintlich private Variablen oder Funktionen zugreifen müssen. Und wenn wir das tun, sind wir mit den Folgen allein fertig.

@sanchopanca

1. GDScript ist nicht Python.
2. Nach Ihrer Logik werden auch keine Konstanten benötigt (var CONSTANT = 1).
3. Nicht jeder verwendet gerne __ .

Ich bin für das Schlüsselwort private , es wird nicht einmal die Kompatibilität beeinträchtigen.
Stattdessen würde die Verwendung von func und var mit _ die Dinge für einige ändern, die es aus anderen Gründen verwenden (ich verwende _ nur in den Parametern der Funktion). ).

Es erinnert mich an die neue statische Tippfunktion und diese private und virtuelle Funktion würde in die gleiche Richtung gehen.
Es würde eine klarere Codebasis mit besserer Fehlererkennung, besserer Autovervollständigung und auch automatischer Dokumentation des Codes bieten.
Wenn jemand Ihren Code liest, würde er besser verstehen, was er tut.

Ich frage mich, wie schwer es für das Entwicklerteam wäre, zwei neue Schlüsselwörter zu implementieren.
Es wäre mit Sicherheit viel einfacher als ein Typsystem und würde viel Wert bieten.
Wenn mir jemand aus dem Entwicklerteam Tipps geben könnte, was zu tun ist, würde ich mich freuen, ehrlich zu sein!

Nur um eine weitere Stimme für das Hinzufügen privater und geschützter Schlüsselwörter hinzuzufügen.
Wenn Sie jemals Code geschrieben haben, den ein anderer Entwickler verwenden wird, können Sie nicht dagegen sein.
Alle gegen das Hinzufügen eines Keywords können dieses Thema überprüfen:
https://softwareengineering.stackexchange.com/questions/143736/why-do-we-need-private-variables

Wir werden weiterhin GDscript verwenden, aber warum es nicht dabei verbessern?

_, __, ___ usw. ist genauso dumm wie das Hinzufügen von Präfixen zu Variablennamen, um Typen vorzuschlagen
intAge, strName, bIsAlive... all diese zeigen nur fehlende Sprachfeatures.
Auch ohne GDScript mit Python oder anderen Sprachen zu vergleichen, kann der Entwickler eine Umfrage durchführen, um zu sehen, ob die Mehrheit diese beiden Schlüsselwörter möchte oder nicht;)

Wenn das Feature implementiert ist, hoffe ich, dass der C++-Weg gewählt wird. Das Schlüsselwort "private" oder "public" vor jeder Deklaration macht das Lesen von C# umständlich.

Ich persönlich würde den C++-Weg nicht mögen, da wir nicht die C++-Typisierungssyntax haben und alles standardmäßig öffentlich wäre. Ich würde es Wert haben, eine Variable auf private setzen zu können, ohne eine weitere Zeile hinzuzufügen - oder sie in eine neue Zeile zu verschieben - mehr als das private Schlüsselwort oft zu sehen.

private var foo : String = "foobar" eher der Verwendung der bestehenden Schlüsselwörter export und onready .

Schließung zugunsten von https://github.com/godotengine/godot-proposals/issues/641 , da Feature-Vorschläge jetzt im Godot-Vorschlags-Repository verfolgt werden.