Godot: Variáveis ​​privadas ou funções em GDScript

A coisa mais próxima para variáveis ​​é usar setget para conduzir a uma função que não faz nada ou imprime um aviso. Mas não, nenhuma verdadeira variável ou função privada.

@YeldhamDev Infelizmente, setget é útil, mas se você não quiser ver uma propriedade pública - não há como fazer isso. Isso é ruim, @reduz o que você acha?

Também não é possível em Python: mesmo o sublinhado duplo inicial não o impede de acessar e modificar variáveis. Em Python, você usa convenções: um sublinhado inicial para indicar que uma variável é privada, ALL_CAPS para indicar que algo é uma constante ... eles ainda estão acessíveis de qualquer lugar, mas na prática não é um problema.

@NathanLovato Talvez o GDScript deva ser diferente do Python nesse caso?

@Chaosus Você deve fornecer argumentos para explicar porque as variáveis ​​privadas são necessárias. Do contrário, é improvável que alguém comece a trabalhar nisso.

As variáveis ​​privadas estão aqui para ajudar a encapsular dados e evitar o acoplamento com outras classes - impede que outras classes acessem essas variáveis. Se você não acessá-los em primeiro lugar, o problema também será resolvido.

Em ambos os casos - usando a palavra-chave privada ou escrevendo usando uma convenção - você tem que aprender quando e como tornar as variáveis ​​privadas, quando e como você deve ser capaz de acessá-las. Você tem que aprender a projetar suas classes para que possa alterar os internos posteriormente sem quebrar sua interface e vice-versa. Acho que essa é a sua maior fonte de problemas quando se trata de arquitetura de código.

Em relação ao Python, ele funciona para milhões de desenvolvedores Python. Existe um mecanismo para tornar as variáveis ​​"privadas", que impede o acesso direto, e é simples: escreva dois sublinhados à esquerda em vez de um. Mas ainda estou para ver alguém usá-lo. Ele não estava disponível em JS até recentemente. Provavelmente existem outras linguagens como essa.

Não estou dizendo que não deveria estar no GDscript - eu realmente não me importo se outras pessoas fizerem um bom uso desse recurso. Só não estou convencido de que seja útil. Por exemplo, Godot pode simplesmente não listar variáveis ​​com um _ ou dois à esquerda no preenchimento automático (embora use _function_name como uma convenção para funções virtuais)?

Eu só não quero ver um método interno com intellisense em GDScript, e torná-lo mais parecido com C # e outras linguagens de tipo estático

Sim, concordo que é difícil de implementar e requer uma nova palavra-chave, muito esforço para um resultado muito pequeno
A solução com o prefixo "__" resolve parcialmente o problema, obrigado, (nunca trabalhei com Python, então é algo novo para mim).

Sei que já está fechado e arquivado (não tenho certeza se deve haver outro problema aberto para isso), mas os modificadores de acesso são um recurso muito importante em qualquer linguagem de programação. Se eu quiser criar um novo complemento de nó para Godot e meu novo nó tiver variáveis ​​de estado internas que não devem ser modificadas fora do nó, não há nada que impeça que isso aconteça. Eu entendo que você pode usar sublinhados à esquerda para imitar esse recurso, mas ainda não impede o acesso, que é o ponto inteiro dos modificadores de acesso. Na minha opinião, isso é muito importante, pois não há como controlar a maneira como outras pessoas interagem com seus objetos.

Sim, concordo com @dylmeadows , seria útil desta forma

Eu sou definitivamente pró funções e variáveis ​​privadas também.

1. Sim, temos uma convenção para private usando um _ na frente do nome de um método, MAS a mesma convenção é usada para funções virtuais. Portanto, se eu vir um sublinhado, isso pode significar "não toque nessa função de forma alguma!" ou "sobrescrever essa função!". Isso é muito perigoso, honestamente.

2. Se estou trabalhando sozinho ou em uma equipe muito pequena em um projeto pequeno, não pesa muito porque sei quais funções devem ser usadas e quais funções são apenas para uso interno.
   Mas com equipes em crescimento, isso fica cada vez mais difícil. As pessoas trabalham com classes que não escreviam sozinhas o tempo todo e eu, como sou uma pessoa que escreve muitas pequenas funções internas para fazer as coisas funcionarem, quero muito poder evitar que as pessoas chamem essas funções, porque se usarem aqueles que podem levar a um comportamento não intencional e bugs e leva tempo para consertar essas coisas uma vez que os erros são cometidos. E apesar de uma convenção comum, essas coisas estarão acontecendo em uma equipe maior, porque afinal de contas, podem ser chamadas de fora.

3. Por último mas não menos importante; conclusão automática. Eu sou alguém que usa muito isso para aprender o que uma classe pode fazer.
   Acabei de colocar '.' no final e veja quais funções aparecem. Se algo parece útil, eu o uso.
   Seria muito mais limpo se não estivesse sobrecarregado com todas as funções que não deveriam ser chamadas de qualquer maneira. Além disso - e novamente - eu ainda não sei se essas funções _name são privadas ou virtuais.

Além disso, as variáveis ​​privadas podem até ser úteis em um projeto pessoal. Às vezes, há períodos de tempo em que não consigo trabalhar no jogo em que estou trabalhando, então começo a esquecer o que algumas de minhas funções fazem. Ou esqueço quais devo e não devo usar.

Variáveis ​​privadas seriam ótimas com isso! Isso garantiria que uma variável ou função não pudesse ser acessada fora de um Nó e, quando voltasse para um projeto, poderia adivinhar como usar uma variável e não ter que ler todo o meu código completamente novamente.

Eu concordo com o que Byteron e Dylmeadows disseram também. Eles apenas escreveram seus posts bem o suficiente e disseram exatamente o que eu estava pensando. Só queria adicionar meus dois centavos.

Vou reabrir porque vários usuários estão interessados ​​e querem discutir isso. Ainda não está planejado, mas podemos discutir e ver se há um forte interesse na comunidade.

Python não é a melhor linguagem mencionada como ideal.
Afirmou-se que Godot é muito orientado a objetos. Cada script também é um objeto. Um dos principais princípios da programação orientada a objetos é fornecer encapsulamento. se eu quero ter algo intocado de fora, é provavelmente pelos melhores motivos.

Eu pessoalmente nunca encontrei um momento em que eu realmente precisasse evitar que as pessoas editassem variáveis ​​ou acessassem uma função. Sempre que gostaria de dizer às pessoas para não mexerem em algo a menos que saibam o que estão fazendo, prefixo o nome com _ (ou _internal_ ou similar).

Eu não faria objeções a uma palavra-chave (ou semelhante) que simplesmente ocultaria a variável / função do preenchimento automático. Só não acho que impedir totalmente o acesso seja necessário.

Por outro lado, é melhor advertir, não proibir. Por outro lado, os campos e métodos privados geralmente são usados ​​muitas vezes. E nomes longos de variáveis ​​(por exemplo, _internal_variable ) são um pouco irritantes.
Em qualquer caso, a presença da palavra-chave private não o obriga a usá-la.

Membros privados da classe para algo como constantes. Da mesma forma, podemos escrever o nome da variável em BIG LETTERS e concordar que não alteraremos seu valor. Mas nós não fazemos isso, fazemos? Ou seja, as variáveis ​​privadas são um cruzamento entre variáveis ​​comuns e constantes. Por que não inserir uma palavra-chave especial para este caso?

Sim, temos uma convenção para private usando um _ na frente do nome de um método, MAS a mesma convenção é usada para funções virtuais. Portanto, se eu vir um sublinhado, isso pode significar "não toque nessa função de forma alguma!" ou "sobrescrever essa função!". Isso é muito perigoso, honestamente.

Esse é o maior problema que vejo aqui. Em vez da palavra-chave private , talvez pudéssemos ter uma palavra-chave virtual ? Alguns métodos virtuais já aparecem no preenchimento automático quando você escreve "func", então uma palavra-chave para diferenciar explicitamente entre as funções virtuais que você deve substituir e as funções privadas que não deveriam aparecer no preenchimento automático pode ser suficiente. O benefício da palavra-chave virtual é que você a usará com menos frequência do que private , portanto, é menos escrita.

Eu ficaria feliz em ver alunos particulares incluídos também. Há uma razão para isso existir em outros idiomas. Outros consumidores / membros da equipe (ou mesmo você) não precisam saber como todas as aulas funcionam. Na verdade, eles talvez nem devessem ter a opção de brincar com funcionalidades que deveriam ser internas de qualquer maneira.

Eu entendo que o sublinhado inicial deve "indicar" que este é um membro privado, mas na prática ninguém se importa se de alguma forma modificá-lo faz o trabalho funcionar. Isso é especialmente doloroso se você quiser usar parte dele como um plug-in e todos podem simplesmente alterar o que quiserem. Eu gostaria de ter controle total sobre o estado de qualquer objeto / script que eu criar. Ter objetos que podem mudar qualquer aspecto de seu estado sempre que alguém quiser torna a produção de código que outros podem consumir mais do que irritante.

Além de tudo isso, seria ótimo organizar a lista de variáveis ​​/ funções "disponíveis".

Posso fazer uma recomendação para a equipe de desenvolvimento, então, por favor, considere tudo isso? Alterar a ordem da lista de preenchimento automático. Qualquer var ou função que não comece com uma letra ou número aparece no __Bottom__ da lista de autocompletar. Em seguida, você praticamente precisa digitar _ para ver o item. Além disso, seria bom se pudéssemos usar outros símbolos não matemáticos ou lógicos nos nomes? Ainda não tentei, mas € Display ou ¥ Print seriam nomes de funções aceitáveis? Etc.

Além disso, seria bom se pudéssemos usar outros símbolos não matemáticos ou lógicos nos nomes. Ainda não tentei, mas € Display ou ¥ Print seriam nomes de funções aceitáveis? Etc.

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

Então, depois de mexer nisso, cheguei à conclusão de que se você definir um setter que não faz nada, mesmo se você tentar atribuir um novo valor às mesmas variáveis ​​em um script diferente e tentar imprimi-lo, o valor original será impresso. Não é realmente privado, mas acho que é perto o suficiente ...

o que significa que não há qualquer dica de que a variável que parece ser pública e que você acabou de modificar não foi alterada?
vamos nos divertir depurando códigos que usam esse método extensivamente.

Em vez do setter vazio, você também pode imprimir um erro.

Ainda sei apenas que fiz algo que não deveria ter feito, uma vez que inicio o programa e realmente acerto aquela linha de código. Ele ainda parece ser público ao escrever o código e ainda requer várias linhas de código para configurar uma única variável privada.
Colocar private na frente dessa variável é muito mais curto, não requer nenhuma linha de código adicional e me impediria de acessá-los erroneamente no momento em que o digito.

GDScript parece bastante C ++ - ish para mim, apesar do fato de que é uma linguagem dinâmica. Quando eu mudo de escrever código em C ++ para GDScript, sinto falta desses modificadores de acesso. Dito isso, o GDScript não tem suporte total para OOP.

Eu apenas dei uma olhada neste problema, mas seria bom pelo menos ser capaz de ocultar funções e variáveis ​​do preenchimento automático se seus nomes fossem prefixados com um sublinhado. Acho que o problema principal com isso é determinar se é uma função virtual e, portanto, provavelmente deve aparecer independentemente

O fato é que o sublinhado também é usado para funções virtuais, e certamente há casos em que você deseja que as funções virtuais também sejam públicas.

Talvez oculte funções com prefixo de sublinhado de outros nós / objeto apenas, mas mostre-as para chamadas em self / base.

Minha sugestão seria usar sublinhado único para funções virtuais e sublinhado duplo inicial para funções "privadas". Desta forma, podemos ocultá-los do autocompletar sem afetar as funções virtuais.

Usar sublinhados para ocultar uma variável é ruim porque quando você altera o acesso _atributo_ da variável, você deve alterar seu _nome_. Na verdade, variable e _variable são nomes diferentes.
Isso também é como um ponto nos nomes dos arquivos UNIX: uma decisão bastante controversa.

Aqui está minha opinião

• Prefixo com "__" para funções privadas
• Funções com "__" não aparecem no preenchimento automático
• "função privada x ()" é um açúcar sintático para "função __x ()"

O código acima quebra qualquer código que inclua uma variável com o prefixo "__". Mas, tirando isso, acho que esse sistema seria o ideal.

Os recursos do GDScript são muito semelhantes aos do Python / JS, e ambas as linguagens não têm variáveis ​​e funções privadas por um bom motivo - é uma antítese completa de sua filosofia de design. Você tem a liberdade, e essa liberdade é importante, é o que torna mais fácil codificar. Você sacrifica o encapsulamento, mas essa é a filosofia deles. O encapsulamento verdadeiro já está quebrado sem a verificação de tipos [a menos que você verifique todos os tipos, o que provavelmente não fará]. Portanto, a menos que implementem tipagem estrita, as variáveis ​​privadas parecem erradas. No gradiente de OOP, a tipagem estrita vem antes das variáveis ​​privadas. Existem muitos idiomas com tipagem estrita, mas sem variáveis ​​privadas, mas não conheço nenhum idioma com variáveis ​​privadas e sem digitação estrita. Novamente, por um bom motivo. Além disso, JS ainda dá acesso a toda a árvore de herança e permite que você altere esses aspectos também. Você pode alterar a classe da qual um objeto herda durante o tempo de execução, por qualquer pedaço de código que tenha o seu objeto! Claro, isso não acontece, mas mostra a filosofia do design.

Então, na minha opinião, verdadeiras variáveis ​​privadas atrapalhariam drasticamente a linguagem. De qualquer forma, acho que o sistema Python faz isso bem, você tem __ que pode usar para acessar as variáveis ​​privadas, mas deixa claro que você está mexendo com algo interno e, ainda assim, não o restringe de forma significativa. Qualquer pessoa que deseja uma verdadeira filosofia de design OOP simplesmente nunca pode usar "__", ou tê-lo no estilo de codificação de sua empresa ou projeto. Talvez uma opção para marcá-lo como um erro seja bom. Quero dizer, em geral, a digitação de pato e as variáveis ​​privadas realmente não combinam. No mínimo, você bagunça totalmente o namespace, porque agora o quê, obj.set ("hi", 5) não funciona se "hi" for privado? Mas funciona se "oi" não existir? Isso não faz muito sentido ... Então, um não muito forte para forçar private a ser completamente inacessível não importa o que você faça, esse é o meu voto. Muito forte, sim, para que as variáveis ​​privadas existam da maneira como o Python o faz atualmente. Ainda não tenho certeza de como resolver o problema de digitação de pato com variáveis ​​privadas de qualquer maneira, mesmo que o desejo fosse ter variáveis ​​privadas verdadeiras e inacessíveis. Eu acho que você apenas bloqueia obj.set e faz com que ele lance um erro. Agora obj.set precisa retornar um booleano ao que parece, o que é estranho. Uma chamada is_private? Isso você deve chamar antes de cada uso de obj.set? Sei lá

[Oh meu Deus, realmente podemos obter detecção de erro real, estamos falando sobre variáveis ​​privadas, mas a partir de agora, se você tiver um bug no gdscript, o jogo irá apenas ignorá-lo silenciosamente (facepalm). Talvez eu esteja fazendo errado, mas se meu código faz algo ilegal, gdscript parece apenas retornar null da função, o que torna tão difícil rastrear, JS sempre foi tão ruim e JS é uma linguagem confusa. Sei que travar o jogo pode ser demais, mas continuo tendo que apenas pesquisar binário minha base de código, colocando instruções de impressão até encontrar duas instruções de impressão consecutivas em que a primeira imprime e a última não, apenas para descobrir onde o código foi quebrado. JS / Python são surpreendentemente muito mais rígidos nesse sentido, apesar de serem livres em todo o resto.]

Sugiro encontrar uma organização de projeto consistente para minimizar o problema. Você pode usar o nó raiz de uma cena como interface para controlar a cena de fora e um script filho como backend.

Alternativamente, você pode usar apenas métodos, exportar variáveis ​​e sinais, e nunca tocar nas variáveis ​​simples de fora. Essa é uma convenção simples e o GDScript pode manter sua simplicidade.

Também não é possível em Python: mesmo o sublinhado duplo inicial não o impede de acessar e modificar variáveis. Em Python, você usa convenções: um sublinhado inicial para indicar que uma variável é privada, ALL_CAPS para indicar que algo é uma constante ... eles ainda estão acessíveis de qualquer lugar, mas na prática não é um problema.

Eu só quero dizer que é possível ter o atributo _private_ em Python.

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

__double_leading_underscore: ao nomear um atributo de classe, invoca name muting (dentro da classe FooBar, __boo se torna _FooBar__boo; veja abaixo).

__double_leading_and_trailing_underscore__: objetos ou atributos "mágicos" que vivem em namespaces controlados pelo usuário. Por exemplo, __init__, __import__ ou __file__. Nunca invente esses nomes; use-os apenas conforme documentado

Se você clicar nesse link e CTRL + F "privado", você obterá

Não usamos o termo "privado" aqui, uma vez que nenhum atributo é realmente privado no Python (sem uma quantidade geralmente desnecessária de trabalho).

As variáveis ​​de sublinhado duplo ou sublinhado único agem como variáveis ​​normais, é apenas uma convenção referenciar que não devem ser usadas e podem mudar quando você atualiza uma biblioteca porque são internas. Em geral, uma vez que linguagens pythônicas como GDScript tratam objetos como se fossem apenas dicionários, seria estranho tentar forçar variáveis ​​privadas e fazer com que elas consumissem o namespace.

Se você clicar nesse link e CTRL + F "privado", você obterá

Não usamos o termo "privado" aqui, uma vez que nenhum atributo é realmente privado no Python (sem uma quantidade geralmente desnecessária de trabalho).

As variáveis ​​de sublinhado duplo ou sublinhado único agem como variáveis ​​normais, é apenas uma convenção referenciar que não devem ser usadas e podem mudar quando você atualiza uma biblioteca porque são internas. Em geral, uma vez que linguagens pythônicas como GDScript tratam objetos como se fossem apenas dicionários, seria estranho tentar forçar variáveis ​​privadas e fazer com que elas consumissem o namespace.

Eu concordo, eles não chamam isso de atributo _privado_. No entanto, deixe-me descrever como 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'

Portanto, não é chamado de atributo _privado_, mas se comporta quase como tal.
Seria ótimo ter um atributo quase privado no GDScript como existe no Python.

Sim, concordo totalmente com você. Python está simplesmente fornecendo açúcar sintático para usar ._Employee__salary. Eu pessoalmente não gosto da maneira como o python faz isso e acho que pode ser bastante melhorado em Godot, como mencionei em meu comentário,

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

O que é mais limpo porque _Employee__salary é uma maneira feia de ocultar o nome da variável, e ter uma palavra-chave privada o torna semelhante ao OOP normal. Melhor ainda, isso bloqueia a capacidade de ter um salário variável público e uma variável privada _salary, o que seria feio e deveria ser um erro de sintaxe, exatamente como em Java. Isso ocorre porque ambos seriam declarados "salário var" e "salário var privado", um conflito claro. Outra maneira de pensar seria "Para acessar a variável privada de alguma outra classe C com o membro m, você deve usar um sublinhado como em C._m". Poderíamos, então, cometer um erro declarar uma variável começando com um sublinhado, ou seja, tornar privada a única maneira de declará-la, para que fique claro o que está sendo feito.

Acho que a única razão pela qual python tem a situação menos desejável que tem rn é porque não há declarações no topo para as variáveis, você apenas cria as variáveis ​​de classe em qualquer um dos corpos de função. O GDScript parece exigir declarações no corpo da classe, facilitando o acesso às declarações privadas semelhantes a Java.

Não gosto de palavras-chave que agem como açúcar de sintaxe, a menos que economizem muita digitação. Aqui, digitar private fará com que você escreva mais caracteres, o que o torna um anti-atalho: ligeiramente_smiling_face:

Além disso, e quanto aos métodos? Vários métodos virtuais começam com um sublinhado, portanto, não podemos usar um único sublinhado para marcá-los como privados. Poderíamos usar dois sublinhados, porém, o que evitaria conflitos em detrimento de ser mais longo. Também gosto da ideia de seguir as convenções do Python quando faz sentido - o "dunder" é popular há algum tempo nessa linguagem.

Não acho que a intenção seja que seja visto como um atalho, em vez disso, a ideia é que fora da classe, você use "_" para acessar variáveis ​​privadas. O açúcar da sintaxe seria como ele é implementado. Essencialmente idêntico ao modo como o python faz isso. Mas, como sim, é verdade, no caso do python, o açúcar da sintaxe economiza muita digitação, mas isso é apenas porque se transforma em algo longo estúpido. Aliasing em algo mais curto é estritamente melhor, portanto, ter um alias mais curto e, em seguida, escolher não ter esse açúcar de sintaxe porque o alias é muito curto, apenas se resume a se devemos ou não suportar variáveis ​​privadas em tudo; não precisamos, podemos apenas fazer com que os usuários prefixem variáveis ​​com sublinhados ou escolham sua própria convenção. É apenas para as pessoas que pensam em Java e C ++, que preferem escrever "private var myvariable" em vez de apenas tomar "_myvariable" como privada como uma convenção, o que parece estranho vindo de um mundo OOP, mesmo que ambos realizem exatamente o mesma coisa. O sublinhado duplo combinaria muito bem com a sintaxe do Python, então estou disposto a isso também, especialmente se _ conflitar com outras coisas

Eu prefiro ter uma palavra-chave que defina explicitamente o comportamento fora do que pode ser mal interpretado como apenas convenções de estilo. private tem meu voto.

Adicionando fogo à discussão: a convenção de estilo python para membros "privados" é adicionar um sublinhado antes do nome, que é _already_ usado pelo gdscript para uma finalidade diferente em métodos de eventos comuns como _ready() , _input e _physics_process , para citar alguns. Eles deveriam ser privados? Como adicionar uma palavra-chave privada interagiria com esses métodos? Outras palavras-chave como protected também precisam ser implementadas?

Em qualquer caso, eu sou a favor de impor diretivas restritivas _por design_ em vez de apenas permitir que os usuários definam convenções. Mas não tenho certeza se os alunos particulares dariam a melhoria pretendida, dada a complexidade da implementação. A API inteira também teria que ser revisada, eu imagino. Toda a linguagem teria um paradigma completamente diferente.

Sim, alguém já notou isso. (Veja a resposta de Calinou) Sublinhado duplo seria o caminho a percorrer. Igual ao Python também.

Meu 2c. Em Python, nada impede que alguém acesse membros da classe que começam com _ , e com algum conhecimento interno com __ .

É tudo uma questão de mostrar intenção. A filosofia é que somos todos adultos, podemos decidir se realmente precisamos acessar variáveis ​​ou funções supostamente privadas. E se fizermos isso, estaremos por conta própria para lidar com as consequências.

@sanchopanca

1. GDScript não é Python.
2. Seguindo sua lógica, constantes também não são necessárias (var CONSTANT = 1).
3. Nem todo mundo gosta de usar __ .

Eu defendo a palavra-chave private , ela nem quebra a compatibilidade.
Em vez disso, tornar func e var privados usando _ , mudaria as coisas para alguns usando-o por outras razões (eu uso _ apenas em parâmetros de função )

Isso me lembra do novo recurso de digitação estática e esse recurso privado e virtual funcionaria da mesma forma.
Forneceria uma base de código mais clara, com melhor detecção de erros, melhor autocompletar e também autodocumentação do código.
Se alguém ler seu código, entenderá melhor o que ele faz.

Estou me perguntando como seria difícil implementar duas novas palavras-chave para a equipe de desenvolvimento.
Seria muito mais fácil do que um sistema de digitação e forneceria muito valor.
Se alguém da equipe de desenvolvimento pudesse me dar dicas sobre o que fazer, ficaria feliz em ajudar para ser honesto!

Apenas para adicionar mais um voto para adicionar palavras-chave privadas e protegidas.
Se você já escreveu um código que algum outro desenvolvedor vai usar, não pode ser contra isso.
Tudo contra a adição de uma palavra-chave pode verificar este tópico:
https://softwareengineering.stackexchange.com/questions/143736/why-do-we-need-private-variables

Ainda vamos usar GDscript, mas por que não torná-lo melhor no processo.

_, __, ___ e assim por diante é simplesmente estúpido tanto quanto adicionar prefixos a nomes de variáveis ​​para sugerir tipos
intAge, strName, bIsAlive ... todos eles mostram apenas os recursos de linguagem ausentes.
Portanto, mesmo sem comparar GDScript com Python ou outras linguagens, o desenvolvedor pode executar uma enquete para ver se a maioria quer ou não essas duas palavras-chave;)

Se o recurso for implementado, espero que a forma C ++ seja escolhida. A palavra-chave "privado" ou "público" antes de cada declaração torna o C # complicado para leitura.

Eu pessoalmente não gostaria do modo C ++, já que não temos a sintaxe de digitação C ++ e tudo seria público por padrão. Eu valorizava ser capaz de definir uma variável como privada sem adicionar outra linha - ou movê-la para uma nova linha - mais do que não ver muito a palavra-chave privada.

private var foo : String = "foobar" está mais de acordo com o uso das palavras-chave export e onready também.

Fechamento em favor de https://github.com/godotengine/godot-proposals/issues/641 , já que as propostas de recursos agora são rastreadas no repositório de propostas Godot.