Godot: Variables privadas o funciones en GDScript

Lo más parecido a las variables es usar setget para llevar a una función que no hace nada o imprime una advertencia. Pero no, no hay verdaderas variables o funciones privadas.

@YeldhamDev Lamentablemente, setget es útil, pero si no desea ver una propiedad pública, no hay forma de hacerlo. Eso es malo, @reduz ¿qué te parece?

Tampoco es posible en Python: incluso el doble subrayado inicial no le impide acceder a las variables y modificarlas. En Python, usa convenciones en su lugar: un guión bajo inicial para indicar que una variable es privada, ALL_CAPS para indicar que algo es una constante ... todavía son accesibles desde cualquier lugar, pero en la práctica no es un problema.

@NathanLovato ¿ Quizás GDScript debería diferir de Python en ese caso?

@Chaosus Debes proporcionar argumentos para explicar por qué son necesarias las variables privadas. De lo contrario, es poco probable que alguien se ponga a trabajar en esto.

Las variables privadas están aquí para ayudar a encapsular datos y evitar el acoplamiento con otras clases; evita que otras clases accedan a estas variables. Si no accede a ellos en primer lugar, el problema también se resuelve.

En ambos casos, usando la palabra clave privada o escribiendo usando una convención, debe aprender cuándo y cómo hacer que las variables sean privadas, cuándo y cómo debería poder acceder a ellas. Tienes que aprender a diseñar tus clases para que luego puedas cambiar los internos sin romper su interfaz y viceversa. Creo que esa es su mayor fuente de problemas cuando se trata de arquitectura de código.

En cuanto a Python, funciona para millones de desarrolladores de Python. Existe un mecanismo para hacer que las variables sean "privadas", que impide el acceso directo, y es simple: escriba dos guiones bajos iniciales en lugar de uno. Pero todavía no he visto a nadie usarlo. Tampoco ha estado disponible en JS hasta hace poco. Probablemente hay otros idiomas como ese.

No estoy diciendo que no debería estar en GDscript; realmente no me importa si otras personas hacen un buen uso de la función. Simplemente no estoy convencido de que sea tan útil. Por ejemplo, Godot simplemente no podría enumerar las variables con un _ inicial o dos en el autocompletado (aunque sí usa _function_name como convención para funciones virtuales).

Simplemente no quiero ver métodos internos con intellisense en GDScript, y hacerlo más como C # y otros lenguajes de tipo estático

Sí, estoy de acuerdo en que es difícil de implementar y requiere una nueva palabra clave, demasiado esfuerzo para un resultado muy pequeño.
La solución con el prefijo "__" resuelve parcialmente el problema, gracias (nunca trabajé con Python, así que es algo nuevo para mí).

Sé que esto ya está cerrado y archivado (no estoy seguro de si debería haber otro problema abierto para esto), pero los modificadores de acceso son una característica bastante importante en cualquier lenguaje de programación. Si quiero crear un nuevo complemento de Nodo para Godot y mi nuevo nodo tiene variables de estado internas que no deben modificarse fuera del Nodo, no hay nada que impida que eso suceda. Entiendo que puede usar guiones bajos iniciales para imitar esta función, pero aún así no impide el acceso, que es el punto principal de los modificadores de acceso. En mi opinión, esto es un gran problema, ya que no hay forma de controlar la forma en que los demás interactúan con sus objetos.

Sí, estoy de acuerdo con @dylmeadows , sería útil de esta manera

Definitivamente también soy pro funciones y variables privadas.

1. Sí, tenemos una convención para el uso privado de un _ delante del nombre de un método, PERO se usa la misma convención para las funciones virtuales. Entonces, si veo un guión bajo, podría significar "¡de ninguna manera tocar esa función!" o "sobrescribir esa función". Eso es muy peligroso, honestamente.

2. Si trabajo solo o en un equipo muy pequeño en un proyecto pequeño, no pesa demasiado porque sé qué funciones deben usarse y qué funciones son solo para uso interno.
   Pero con equipos en crecimiento, esto se vuelve cada vez más difícil. La gente trabaja con clases que no escriben ellos mismos todo el tiempo y yo, como soy una persona que escribe muchas funciones internas pequeñas para que las cosas funcionen, realmente quiero poder evitar que la gente llame a estas funciones, porque si usan aquellos que pueden dar lugar a errores y comportamientos involuntarios, y cuesta tiempo corregirlos una vez que se cometen los errores. Y a pesar de una convención común, estas cosas sucederán en un equipo más grande, porque, después de todo, se pueden llamar desde afuera.

3. Por último, si bien no menos importante; finalización automática. Soy alguien que usa mucho esto para aprender lo que puede hacer una clase.
   Solo puse eso '.' al final y vea qué funciones aparecen. Si algo suena útil, lo uso.
   Sería mucho más limpio si no estuviera abarrotado de todas esas funciones que se supone que no deben llamarse de todos modos. Además, y nuevamente, todavía no sé si estas funciones _name son privadas o virtuales.

Además, las variables privadas incluso pueden ser útiles en un proyecto personal. A veces hay períodos de tiempo en los que no puedo trabajar en el juego en el que estoy trabajando, así que empiezo a olvidar lo que hacen algunas de mis funciones. O olvido cuáles debo y cuáles no debo usar.

¡Las variables privadas serían geniales con esto! Se aseguraría de que no se pueda acceder a una variable o función fuera de un Nodo, y cuando vuelva a un proyecto, podría adivinar cómo usar una variable y no tener que leer todo mi código por completo nuevamente.

También secundo lo que dijeron Byteron y dylmeadows. Simplemente escribieron sus publicaciones lo suficientemente bien y dijeron exactamente lo que estaba pensando. Solo quería agregar mis dos centavos.

Volveré a abrir ya que varios usuarios están interesados ​​y quieren discutir esto. Todavía no está planeado, pero podemos discutir y ver si hay un gran interés en la comunidad.

Python no es el mejor lenguaje mencionado como ideal.
Se ha dicho que Godot está muy orientado a objetos. Cada guión es también un objeto. Uno de los principios fundamentales de la programación orientada a objetos es la encapsulación. si quiero tener algo intacto desde el exterior, probablemente sea por las mejores razones.

Personalmente, nunca me he encontrado con un momento en el que necesite absolutamente evitar que las personas editen variables o accedan a una función. Cada vez que quisiera decirle a la gente que no se meta con algo a menos que sepan lo que están haciendo, prefijo su nombre con _ (o _internal_ o similar).

No me opondría a una palabra clave (o similar) que simplemente ocultaría la variable / función para que no se complete automáticamente. Simplemente no creo que sea necesario impedir el acceso por completo.

Por un lado, es mejor advertir, no prohibir. Pero, por otro lado, los campos y métodos privados se suelen utilizar muchas veces. Y los nombres largos de variables (por ejemplo, _internal_variable ) son un poco molestos.
En cualquier caso, la presencia de la palabra clave private no te obliga a usarla.

Miembros privados de la clase a algo así como constantes. Del mismo modo, podemos escribir el nombre de la variable en LETRAS GRANDES y acordar que no cambiaremos su valor. Pero no hacemos eso, ¿verdad? Es decir, las variables privadas son un cruce entre variables ordinarias y constantes. ¿Por qué no ingresa una palabra clave especial para este caso?

Sí, tenemos una convención para el uso privado de un _ delante del nombre de un método, PERO se usa la misma convención para las funciones virtuales. Entonces, si veo un guión bajo, podría significar "¡de ninguna manera tocar esa función!" o "sobrescribir esa función". Eso es muy peligroso, honestamente.

Ese es el mayor problema que veo aquí. En lugar de private palabra clave, ¿quizás podríamos tener una palabra clave virtual ? Algunos métodos virtuales ya aparecen en autocompletar cuando escribe "func", por lo que una palabra clave para diferenciar explícitamente entre funciones virtuales que se supone que debe sobrescribir y funciones privadas que no deberían aparecer en autocompletar podría ser suficiente. El beneficio de la palabra clave virtual es que la usaría con menos frecuencia que private , por lo que es menos escritura.

Me alegraría que también se incluyeran miembros de la clase privada. Hay una razón por la que esto existe en otros idiomas. Otros consumidores / miembros del equipo (o incluso usted mismo) no necesitan saber cómo funciona cada clase. De hecho, tal vez ni siquiera deberían tener la opción de jugar con la funcionalidad que se supone que es interna de todos modos.

Entiendo que el guión bajo inicial debería "indicar" que se trata de un miembro privado, pero en la práctica a nadie le importa si modificarlo de alguna manera hace el trabajo. Esto es especialmente doloroso si desea usar parte de él como un complemento y todos pueden cambiar lo que quieran. Me gustaría tener un control total sobre el estado de cualquier objeto / script que cree. Tener objetos que pueden cambiar cualquier aspecto de su estado siempre que alguien quiera hacerlo hace que producir código que otros puedan consumir sea más que irritante.

Además de todo eso, sería genial ordenar la lista de variables / funciones "disponibles".

¿Puedo hacer una recomendación al equipo de desarrollo y considerar todo esto? Cambiar el orden de la lista de Autocompletar. Cualquier var o función que no comience con una letra o un número aparece en __Bottom__ de la lista de autocompletar. Entonces tienes que escribir _ para ver el elemento¿ Además, sería bueno si pudiéramos usar otros símbolos no matemáticos o lógicos en los nombres? Aún no lo he probado, pero ¿serían los nombres de función aceptables € Display o ¥ Print? Etc.

Además, sería bueno si pudiéramos usar otros símbolos no matemáticos o lógicos en los nombres. Aún no lo he probado, pero ¿serían los nombres de función aceptables € Display o ¥ Print? Etc.

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

Entonces, después de jugar con esto, llegué a la conclusión de que si define un establecedor que no hace nada, incluso si intenta asignar un nuevo valor a esas mismas variables en un script diferente e intenta imprimirlo, el valor original será impreso. No es realmente privado, pero supongo que está lo suficientemente cerca ...

lo que significa que no hay ningún indicio de que la variable que parece ser pública y que acaba de modificar no haya sido modificada.
Vamos a divertirnos depurando el código que utiliza este método ampliamente.

En lugar de un setter vacío, también puede imprimir un error.

Todavía solo sé que hice algo que no debería haber hecho una vez que encendí el programa y realmente llegué a esa línea de código. Todavía parece ser público mientras escribe código y aún requiere múltiples líneas de código para configurar una sola variable privada.
Poner un private delante de esa variable es mucho más corto, no requiere ninguna línea adicional de código y evitaría que acceda falsamente justo cuando lo escribo.

GDScript me parece bastante C ++, a pesar de que es un lenguaje dinámico. Cuando cambio de escribir código en C ++ a GDScript, echo de menos esos modificadores de acceso. Dicho esto, GDScript carece de soporte completo para OOP.

Solo repasé este problema, pero sería bueno al menos poder ocultar funciones y variables del autocompletado si sus nombres tienen el prefijo de subrayado. Supongo que el problema principal con eso es determinar si se trata de una función virtual y, por lo tanto, probablemente debería aparecer independientemente

Lo que pasa es que el guión bajo también se usa para funciones virtuales, y ciertamente hay casos en los que desea que las funciones virtuales también sean públicas.

Tal vez oculte funciones con prefijo de subrayado de otros nodos / objetos solamente, pero muéstrelas para llamadas en self / base.

Mi sugerencia sería utilizar un guión bajo simple para las funciones virtuales y un guión bajo inicial doble para las funciones "privadas". De esta forma podemos ocultarlos del autocompletado sin afectar las funciones virtuales.

Usar guiones bajos para ocultar una variable es malo porque cuando cambia el _attribute_ de acceso de la variable, debe cambiar su _nombre_. De hecho, variable y _variable son nombres diferentes.
Esto también es como un punto en los nombres de archivo de UNIX: una decisión bastante controvertida.

Esta es mi opinion

• Prefijo con "__" para funciones privadas
• Las funciones con "__" no aparecen en autocompletar
• "private func x ()" es azúcar sintáctico para "func __x ()"

Lo anterior rompe cualquier código que incluya una variable con el prefijo "__". Pero, excluyendo eso, creo que ese sistema sería ideal.

Las características de GDScript hasta ahora son muy similares a Python / JS, y ambos lenguajes no tienen variables y funciones privadas por una muy buena razón: es una completa antítesis de su filosofía de diseño. Tienes la libertad, y esa libertad es importante, es lo que facilita la codificación. Sacrificas la encapsulación, pero esa es su filosofía. La verdadera encapsulación ya está rota sin la verificación de tipos [a menos que usted mismo verifique todos los tipos, lo que probablemente no hará]. Entonces, a menos que implementen una escritura estricta, las variables privadas se sienten mal. En el gradiente de la programación orientada a objetos, la escritura estricta se antepone a las variables privadas. Hay muchos lenguajes con mecanografía estricta pero sin variables privadas, pero no conozco ningún idioma con variables privadas y sin mecanografía estricta. Esto es nuevamente, por una buena razón. Más allá de eso, JS incluso le da acceso a todo el árbol de herencia y también le permite cambiar esos aspectos. ¡Puede cambiar de qué clase hereda un objeto durante el tiempo de ejecución, por cualquier fragmento de código que tenga su objeto! Por supuesto, eso no sucede, pero muestra la filosofía de diseño.

Entonces, en mi opinión, las verdaderas variables privadas obstaculizarían drásticamente el idioma. De todos modos, creo que el sistema de Python lo hace bien, tienes __ que puedes usar para acceder a las variables privadas, pero deja en claro que estás jugando con algo interno y, sin embargo, no te restringe significativamente. Cualquiera que desee una verdadera filosofía de diseño de programación orientada a objetos simplemente nunca puede usar "__", ni tenerlo en el estilo de codificación de su empresa o proyecto. Quizás una opción para marcarlo como error sería buena. Me refiero a que, en general, la tipificación de pato y las variables privadas no van realmente juntas. Como mínimo, arruinas por completo el espacio de nombres porque ahora, ¿obj.set ("hola", 5) no funciona si "hola" es privado? ¿Pero funciona si "hola" no existe? Eso no tiene mucho sentido ... Entonces, un no muy fuerte para obligar a lo privado a ser completamente inaccesible sin importar lo que hagas, ese es mi voto. Sí muy fuerte para que existan variables privadas de la forma en que Python lo hace actualmente. De todos modos, todavía no estoy seguro de cómo resolver el problema de la escritura de pato con variables privadas, incluso si el deseo era tener variables privadas verdaderas e inaccesibles. Supongo que simplemente bloqueas obj.set y haces que arroje un error. Ahora obj.set necesita devolver un booleano que parece, lo cual es extraño. ¿Una llamada is_private? ¿Que tienes que llamar antes de cada uso de obj.set? no sé

[Oh, Dios mío, de verdad, ¿podemos obtener una detección real de errores? Estamos hablando de variables privadas, pero a partir de ahora, si tienes un error en gdscript, el juego simplemente lo ignorará en silencio (facepalm). Tal vez lo esté haciendo mal, pero si mi código hace algo ilegal, gdscript parece devolver un valor nulo desde la función, lo que hace que sea tan difícil de rastrear, JS alguna vez ha sido tan malo y JS es un desastre de lenguaje. Sé que bloquear el juego puede ser demasiado, pero sigo teniendo que buscar binariamente en mi base de código colocando declaraciones de impresión hasta que encuentro dos declaraciones de impresión consecutivas donde la primera se imprime y la última no, solo para averiguar dónde se rompió el código. JS / Python son sorprendentemente mucho más estrictos en ese sentido, a pesar de lo libres que son en todo lo demás.]

Sugiero encontrar una organización de proyecto consistente para minimizar el problema. Puede usar el nodo raíz de una escena como interfaz para controlar la escena desde el exterior y un script secundario como backend.

Alternativamente, puede usar solo métodos, exportar variables y señales, y nunca tocar las variables simples desde el exterior. Esa es una convención simple y GDScript puede mantener su simplicidad.

Tampoco es posible en Python: incluso el doble subrayado inicial no le impide acceder a las variables y modificarlas. En Python, usa convenciones en su lugar: un guión bajo inicial para indicar que una variable es privada, ALL_CAPS para indicar que algo es una constante ... todavía son accesibles desde cualquier lugar, pero en la práctica no es un problema.

Solo quiero decir que es posible tener el atributo _private_ en Python.

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

__double_leading_underscore: al nombrar un atributo de clase, invoca el cambio de nombre (dentro de la clase FooBar, __boo se convierte en _FooBar__boo; ver más abajo).

__double_leading_and_trailing_underscore__: objetos o atributos "mágicos" que viven en espacios de nombres controlados por el usuario. Por ejemplo, __init__, __import__ o __file__. Nunca invente tales nombres; Úselos solo según lo documentado

Si hace clic en ese vínculo y CTRL + F "privado", obtendrá

No usamos el término "privado" aquí, ya que ningún atributo es realmente privado en Python (sin una cantidad de trabajo generalmente innecesaria).

Las variables de subrayado doble o subrayado simple actúan como variables normales, es solo una convención para hacer referencia a que no deben usarse y pueden cambiar cuando actualiza una biblioteca porque son internas. En general, dado que los lenguajes pitónicos como GDScript tratan los objetos como si fueran solo diccionarios, sería incómodo intentar forzar las variables privadas y hacer que consuman el espacio de nombres.

Si hace clic en ese vínculo y CTRL + F "privado", obtendrá

No usamos el término "privado" aquí, ya que ningún atributo es realmente privado en Python (sin una cantidad de trabajo generalmente innecesaria).

Las variables de subrayado doble o subrayado simple actúan como variables normales, es solo una convención para hacer referencia a que no deben usarse y pueden cambiar cuando actualiza una biblioteca porque son internas. En general, dado que los lenguajes pitónicos como GDScript tratan los objetos como si fueran solo diccionarios, sería incómodo intentar forzar las variables privadas y hacer que consuman el espacio de nombres.

Estoy de acuerdo, no lo llaman atributo _private_. Sin embargo, permítanme describir cómo funciona:

# 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'

Por lo tanto, no se le llama atributo _private_, pero se comporta casi como tal.
Sería genial tener un atributo casi privado en GDScript tal como existe en Python.

Oh, sí, estoy totalmente de acuerdo contigo. Python simplemente le está dando azúcar sintáctico por usar ._Employee__salary. Personalmente, no me gusta la forma en que lo hace Python y creo que se puede mejorar mucho en Godot, como mencioné en mi comentario,

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

Lo cual es más limpio porque _Employee__salary es una forma fea de ocultar el nombre de la variable, y tener una palabra clave privada lo hace como OOP normal. Aún mejor, esto bloquea la capacidad de tener un salario variable pública y un salario variable privado _salary, lo que sería feo y debería ser un error de sintaxis al igual que en Java. Esto se debe a que ambos serían declarados "salario var" y "salario var privado", un claro conflicto. Otra forma de pensar sería "Para acceder a la variable privada de alguna otra clase C con el miembro m, debes usar un guión bajo como en C._m". Entonces podríamos cometer un error al declarar una variable que comience con un guión bajo, es decir, hacer privada la única forma de declararla, de modo que quede claro lo que se está haciendo.

Creo que la única razón por la que python tiene la situación menos deseable que tiene rn es porque no hay declaraciones en la parte superior para las variables, solo inventa las variables de clase en cualquiera de los cuerpos de la función. GDScript parece requerir declaraciones en el cuerpo de la clase, lo que le da una transición fácil a declaraciones privadas similares a Java.

No me gusta tener palabras clave que actúen como azúcar sintáctico a menos que ahorren mucho tipeo. Aquí, escribir private realidad te hará escribir más caracteres, lo que lo convierte en un anti-atajo: mild_smiling_face:

Además, ¿qué pasa con los métodos? Varios métodos virtuales comienzan con un guión bajo, por lo que no podemos usar un solo guión bajo para marcarlos como privados. Sin embargo, podríamos usar dos guiones bajos, lo que evitaría conflictos a costa de ser más largos. También me gusta la idea de seguir las convenciones de Python cuando tiene sentido: el "dunder" ha sido popular durante un tiempo en ese lenguaje.

No creo que la intención sea que se vea como un atajo, en cambio, la idea es que fuera de la clase, use "_" para acceder a las variables privadas. El azúcar de sintaxis sería cómo se implementa. Esencialmente idéntico a cómo lo hace Python. Pero sí, es cierto, en el caso de Python, el azúcar de sintaxis ahorra mucho tipeo, pero eso es solo porque se convierte en un alias en algo estúpido y largo. Poner un alias en algo más corto es estrictamente mejor, por lo que tener un alias más corto y luego elegir no tener ese azúcar de sintaxis porque el alias es demasiado corto, simplemente se reduce a si debemos o no admitir variables privadas; no tenemos que hacerlo, simplemente podemos hacer que los usuarios antepongan las variables con guiones bajos o elijan su propia convención. Es solo para las personas con mentalidad de Java y C ++, que prefieren escribir "private var myvariable" en lugar de simplemente tomar "_myvariable" como privado como una convención, lo que se siente extraño cuando proviene de un mundo de programación orientada a objetos, incluso si ambos logran exactamente lo mismo. la misma cosa. El subrayado doble coincidiría bastante bien con la sintaxis de Python, así que también estoy preparado para eso, especialmente si _ entra en conflicto con otras cosas

Prefiero tener una palabra clave que defina explícitamente el comportamiento fuera de lo que puede malinterpretarse como solo convenciones de estilo. private obtiene mi voto.

Agregando fuego a la discusión: la convención de estilo de Python para los miembros "privados" es agregar un guión bajo antes del nombre, que ya es usado por gdscript para un propósito diferente en métodos de eventos comunes como _ready() , _input y _physics_process , por nombrar algunos. ¿Se supone que son privados? ¿Cómo interactuaría la adición de una palabra clave privada con estos métodos? ¿Deberían implementarse también otras palabras clave como protected ?

En cualquier caso, estoy totalmente a favor de hacer cumplir las directivas restrictivas _por diseño_ en lugar de simplemente permitir que los usuarios definan las convenciones. Pero no estoy tan seguro de que los miembros de la clase privada den la mejora deseada dada la complejidad de la implementación. La API completa también tendría que ser revisada, me imagino. Todo el lenguaje tendría un paradigma completamente diferente.

Sí, alguien ya lo notó. (Vea la respuesta de Calinou) El doble subrayado sería el camino a seguir. Igual que Python también.

Mi 2c. En Python, nada impide que nadie acceda a los miembros de la clase que comienzan con _ , y con algún conocimiento interno tampoco con __ .

Se trata de mostrar intención. La filosofía es que todos somos adultos, podemos tomar la decisión de si realmente necesitamos acceder a variables o funciones supuestamente privadas. Y si lo hacemos, estaremos solos para lidiar con las consecuencias.

@sanchopanca

1. GDScript no es Python.
2. Siguiendo su lógica, las constantes tampoco son necesarias (var CONSTANT = 1).
3. No a todo el mundo le gusta usar __ .

Estoy a favor de la palabra clave private , ni siquiera romperá la compatibilidad.
En cambio, hacer func y var privados usando _ , cambiaría las cosas para unos pocos usándolo por otras razones (uso _ solo en los parámetros de la función ).

Me recuerda la nueva función de escritura estática y esta función privada y virtual funcionaría de la misma manera.
Proporcionaría una base de código más clara, con mejor detección de errores, mejor autocompletado y también auto-documentación del código.
Si alguien lee su código, entenderá mejor lo que hace.

Me pregunto qué tan difícil sería implementar dos nuevas palabras clave para el equipo de desarrollo.
Seguro que sería mucho más fácil que un sistema de mecanografía y aportaría mucho valor.
Si alguien del equipo de desarrollo me pudiera dar consejos sobre qué hacer, ¡estaría feliz de ayudar para ser honesto!

Solo para agregar un voto más para agregar palabras clave privadas y protegidas.
Si alguna vez escribió código que algún otro desarrollador va a usar, no puede estar en contra de eso.
Todos en contra de agregar una palabra clave pueden consultar este tema:
https://softwareengineering.stackexchange.com/questions/143736/why-do-we-need-private-variables

Seguiremos usando GDscript, pero ¿por qué no mejorarlo en el proceso?

_, __, ___, etc. es tan estúpido como añadir prefijos a los nombres de las variables para sugerir tipos
intAge, strName, bIsAlive ... todos estos solo muestran las características del lenguaje que faltan.
Entonces, incluso sin comparar GDScript con Python u otros lenguajes, el desarrollador puede ejecutar una encuesta para ver si la mayoría quiere o no quiere estas dos palabras clave;)

Si se implementa la función, espero que se elija la forma C ++. La palabra clave "privado" o "público" delante de cada declaración hace que C # sea incómodo para la lectura.

Personalmente, no me gustaría la forma de C ++, ya que no tenemos la sintaxis de escritura de C ++ y todo sería público por defecto. Valoraría poder establecer una variable en privada sin agregar otra línea, o moverla a una nueva línea, más que no ver mucho la palabra clave privada.

private var foo : String = "foobar" está más en línea con el uso de las palabras clave existentes export y onready .

Cerrando a favor de https://github.com/godotengine/godot-proposals/issues/641 , ya que las propuestas de funciones ahora se rastrean en el repositorio de propuestas de Godot.