Godot: Частные переменные или функции в GDScript

Самым близким к переменным является использование setget для перехода к функции, которая либо ничего не делает, либо выводит предупреждение. Но нет, никаких настоящих частных переменных или функций.

@YeldhamDev К сожалению, setget полезен, но если вы не хотите видеть общедоступное свойство - нет способа сделать это. Плохо, @reduz, что ты думаешь?

Это невозможно и в Python: даже двойное подчеркивание в начале не мешает вам получать доступ к переменным и изменять их. В Python вместо этого вы используете соглашения: один ведущий знак подчеркивания, чтобы указать, что переменная является частной, ALL_CAPS, чтобы указать, что что-то является константой ... они все еще доступны из любого места, но на практике это не проблема.

@NathanLovato Может быть, в этом случае GDScript должен отличаться от Python?

@Chaosus Вы должны предоставить аргументы, чтобы объяснить, почему необходимы частные переменные. Иначе вряд ли кто-то над этим возьмется.

Частные переменные здесь, чтобы помочь инкапсулировать данные и предотвратить связь с другими классами - это предотвращает доступ других классов к этим переменным. Если вы не обращаетесь к ним с самого начала, проблема тоже решается.

В обоих случаях - с использованием ключевого слова private или написания с использованием соглашения - вы должны узнать, когда и как сделать переменные закрытыми, когда и как вы должны иметь к ним доступ. Вы должны научиться проектировать свои классы так, чтобы впоследствии вы могли изменить внутреннее устройство, не нарушая их интерфейса, и наоборот. Я думаю, что это ваш самый большой источник проблем, когда дело касается архитектуры кода.

Что касается Python, он работает для миллионов разработчиков Python. Существует простой механизм, позволяющий сделать переменные "закрытыми", предотвращающий прямой доступ: вместо одного символа подчеркивания следует писать два символа подчеркивания в начале. Но я еще не видел, чтобы кто-то им пользовался. До недавнего времени он также не был доступен в JS. Наверное, есть и другие подобные языки.

Я не говорю, что этого не должно быть в GDscript - я действительно не возражаю, если другие люди хорошо используют эту функцию. Я просто не уверен, что это так полезно. Например, Годо не мог просто перечислить переменные с начальным _ или двумя в автозаполнении (хотя он использует _function_name как соглашение для виртуальных функций)?

Я просто не хочу видеть внутренние методы с intellisense в GDScript и делать его больше похожим на C # и другие языки со статической типизацией.

Да, я согласен, что это сложно реализовать и требует нового ключевого слова, слишком много усилий для очень крошечного результата
Решение с префиксом «__» частично решает проблему, спасибо (я никогда не работал с Python, поэтому для меня это что-то новое).

Я знаю, что это уже закрыто и заархивировано (не уверен, должна ли быть открыта другая проблема для этого), но модификаторы доступа - довольно важная функция в любом языке программирования. Если я хочу создать новую надстройку узла для Godot, и мой новый узел имеет внутренние переменные состояния, которые не следует изменять за пределами узла, ничто не препятствует этому. Я понимаю, что вы можете использовать начальные подчеркивания, чтобы имитировать эту функцию, но это по-прежнему не препятствует доступу, который является всей точкой доступа модификаторов. На мой взгляд, это довольно большая проблема, поскольку нет способа контролировать то, как другие взаимодействуют с вашими объектами.

Да, я согласен с @dylmeadows, это было бы полезно в этом случае

Я определенно сторонник частных функций и переменных.

1. Да, у нас есть соглашение о частном использовании _ перед именем метода, НО такое же соглашение используется для виртуальных функций. Итак, если я вижу подчеркивание, это может означать либо «ни в коем случае не трогайте эту функцию!» или «перезапишите эту функцию!». Честно говоря, это чертовски опасно.

2. Если я работаю один или в очень маленькой команде над небольшим проектом, это не будет иметь большого значения, потому что я знаю, какие функции предназначены для использования, а какие - только для внутреннего использования.
   Но с ростом команд это становится все труднее и труднее. Люди работают с классами, которые они не писали все время, и я, поскольку я человек, который пишет множество небольших внутренних функций, чтобы все работало, я действительно хочу иметь возможность запретить людям вызывать эти функции, потому что, если они будут использовать те, которые могут привести к непреднамеренному поведению и ошибкам, и исправление этих вещей стоит времени после того, как ошибки будут сделаны. И, несмотря на общее соглашение, эти вещи будут происходить в более крупной команде, потому что они, в конце концов , вызываются извне.

3. Последний, но тем не менее важный; автозаполнение. Я тот, кто много использует это, чтобы узнать, на что способен класс.
   Я просто поставил это '.' в конце и посмотрите, какие функции появятся. Если что-то кажется полезным, я им пользуюсь.
   Было бы намного чище, если бы он не был загроможден всеми теми функциями, которые в любом случае не должны вызываться. Кроме того - и снова - я до сих пор не знаю, являются ли эти функции _name частными или виртуальными.

Кроме того, частные переменные могут быть полезны даже в личном проекте. Иногда бывают периоды времени, когда я не могу работать над игрой, над которой работаю, поэтому я начинаю забывать, что делают некоторые из моих функций. Или я забываю, какие из них мне следует и не следует использовать.

С этим отлично подойдут частные переменные! Это обеспечит невозможность доступа к переменной или функции за пределами узла, и когда я вернусь к проекту, я смогу догадаться, как использовать переменную, и мне не придется заново полностью читать весь мой код.

Я также поддерживаю то, что сказали Байтерон и Дилмедоуз. Просто они достаточно хорошо писали свои посты и говорили именно то, что я думал. Просто хотел добавить свои два цента.

Я открою снова, так как несколько пользователей заинтересованы и хотят обсудить это. Это еще не запланировано, но мы можем обсудить и посмотреть, есть ли у сообщества большой интерес.

Python - не лучший язык, который можно назвать идеальным.
Было заявлено, что Godot очень объектно-ориентирован. Каждый сценарий - это тоже объект. Одним из основных принципов объектно-ориентированного программирования является инкапсуляция. если я хочу иметь что-то нетронутое извне, это, вероятно, по лучшим причинам.

Я лично никогда не сталкивался со временем, когда мне абсолютно необходимо было запретить людям редактировать переменные или получать доступ к функциям. Каждый раз, когда я хотел бы посоветовать людям не связываться с чем-либо, если они не знают, что делают, я добавляю к его имени префикс _ (или _internal_ или аналогичный).

Я бы не стал возражать против ключевого слова (или подобного), которое просто скроет переменную / функцию от автозаполнения. Я просто не думаю, что необходимо полностью предотвращать доступ.

С одной стороны, лучше предупредить, а не запретить. Но с другой стороны, частные поля и методы обычно используются много раз. А длинные имена переменных (например, _internal_variable ) немного раздражают.
В любом случае наличие ключевого слова private не заставляет вас его использовать.

Приватные члены класса к чему-то вроде констант. Точно так же мы можем написать имя переменной БОЛЬШИМИ БУКВАМИ и договориться, что мы не будем изменять его значение. Но мы этого не делаем, не так ли? То есть частные переменные представляют собой нечто среднее между обычными переменными и константами. Почему бы не ввести специальное ключевое слово для этого случая?

Да, у нас есть соглашение о частном использовании _ перед именем метода, НО такое же соглашение используется для виртуальных функций. Итак, если я вижу подчеркивание, это может означать либо «ни в коем случае не трогайте эту функцию!» или «перезапишите эту функцию!». Честно говоря, это чертовски опасно.

Это самая большая проблема, которую я здесь вижу. Может быть, вместо ключевого слова private мы могли бы использовать ключевое слово virtual ? Некоторые виртуальные методы уже появляются в автозаполнении, когда вы пишете "func", поэтому ключевого слова для явного различия между виртуальными функциями, которые вы должны перезаписывать, и частными функциями, которые не должны появляться в автозаполнении, может быть достаточно. Преимущество ключевого слова virtual заключается в том, что вы будете использовать его реже, чем private , так что оно будет меньше писать.

Я был бы счастлив, если бы были включены и частные классы. Есть причина, по которой это существует на других языках. Другим потребителям / членам команды (или даже вам) не нужно знать, как работает каждый класс. Фактически, у них, возможно, даже не должно быть возможности дурачиться с функциональностью, которая в любом случае должна быть внутренней.

Я понимаю, что верхнее подчеркивание должно «указывать» на то, что это закрытый член, но на практике никого не волнует, приведет ли его какое-либо изменение к работе. Это особенно болезненно, если вы хотите использовать некоторые из них в качестве плагинов, и каждый может просто изменить все, что захочет. Я хотел бы иметь полный контроль над состоянием любого создаваемого мной объекта / скрипта. Наличие объектов, которые могут изменить любой аспект своего состояния, когда кому-то захочется, делает создание кода, который могут потреблять другие, более чем раздражает.

Кроме всего прочего, было бы здорово разобрать список «доступных» переменных / функций.

Могу я сделать одну рекомендацию команде разработчиков, тогда, пожалуйста, учтите все это? Измените порядок автозаполнения в списке. Любая переменная или функция, которая не начинается с буквы или цифры, отображается в __Bottom__ списка автозаполнения. Затем вам в значительной степени нужно ввести _, чтобы увидеть элемент¿ Кроме того, было бы неплохо, если бы мы могли использовать в именах другие нематематические или логические символы? Еще не пробовал, но будет ли € Display или ¥ Print приемлемыми именами функций? И т.п.

Кроме того, было бы неплохо, если бы мы могли использовать в именах другие нематематические или логические символы? Еще не пробовал, но будет ли € Display или ¥ Print приемлемыми именами функций? И т.п.

См. Https://github.com/godotengine/godot/issues/24785.

Итак, поработав с этим, я пришел к выводу, что если вы определите сеттер, который ничего не делает, даже если вы попытаетесь присвоить новое значение тем же переменным в другом скрипте и попытаетесь распечатать его, исходное значение будет напечатаны. Это не совсем личное, но я думаю, это достаточно близко ...

Это означает, что нет никакого намека на то, что переменная, которая кажется общедоступной, и вы только что изменили, не была изменена?
хорошо получайте удовольствие от отладки кода, который широко использует этот метод.

Вместо пустого сеттера вы также можете распечатать ошибку.

Я до сих пор знаю только, что сделал то, чего не должен был делать после того, как запустил программу и действительно попал в эту строку кода. При написании кода он по-прежнему кажется общедоступным, и для настройки одной частной переменной по-прежнему требуется несколько строк кода.
Помещение private перед этой переменной намного короче, не требует дополнительных строк кода и помешает мне получить к ним ложный доступ прямо при вводе.

GDScript кажется мне C ++ - иш, несмотря на то, что это динамический язык. Когда я переключаюсь с написания кода на C ++ на GDScript, мне не хватает этих модификаторов доступа. При этом в GDScript действительно отсутствует полная поддержка ООП.

Я только бегло рассмотрел эту проблему, но было бы неплохо, по крайней мере, иметь возможность скрыть функции и переменные от автозаполнения, если их имена имеют префикс с подчеркиванием. Я предполагаю, что основная проблема заключается в том, чтобы определить, является ли это виртуальной функцией, и поэтому, вероятно, она должна появиться независимо от того,

Дело в том, что подчеркивание также используется для виртуальных функций, и, безусловно, есть случаи, когда вы хотите, чтобы виртуальные функции тоже были общедоступными.

Возможно, скрыть функции с префиксом подчеркивания только от других узлов / объектов, но показать их для вызовов на себе / базе.

Я предлагаю использовать одинарное подчеркивание для виртуальных функций и двойное подчеркивание для «частных» функций. Таким образом, мы можем скрыть их от автозаполнения, не затрагивая виртуальные функции.

Использование подчеркивания для скрытия переменной - это плохо, потому что при изменении доступа _attribute_ переменной вам нужно изменить ее _name_. Фактически, variable и _variable - это разные имена.
Это также похоже на точку в именах файлов UNIX: довольно спорное решение.

Вот мое мнение

• Префикс с «__» для частных функций
• Функции с «__» не отображаются при автозаполнении
• "private func x ()" - синтаксический сахар для "func __x ()"

Вышеупомянутое нарушает любой код, который включает переменную с префиксом «__». Но без этого, думаю, эта система была бы идеальной.

Таким образом, возможности GDScript очень похожи на Python / JS, и оба этих языка не имеют частных переменных и функций по очень веской причине - это полная противоположность их философии дизайна. У вас есть свобода, и эта свобода важна, потому что это упрощает программирование. Вы жертвуете инкапсуляцией, но это их философия. Истинная инкапсуляция уже нарушена без проверки типов [если вы сами не проверите все типы, что вы, вероятно, не собираетесь делать]. Так что, если они не реализуют строгую типизацию, частные переменные кажутся неправильными. В градиенте ООП строгая типизация предшествует закрытым переменным. Есть много языков со строгой типизацией, но без частных переменных, но я не знаю языков с частными переменными и без строгой типизации. Это опять же не зря. Помимо этого, JS даже дает вам доступ ко всему дереву наследования и позволяет вам изменять и эти аспекты. Вы можете изменить класс, от которого наследуется объект, во время выполнения с помощью любого фрагмента кода, в котором есть ваш объект! Конечно, этого не происходит, но показывает философию дизайна.

Так что, на мой взгляд, настоящие частные переменные сильно помешали бы языку. В любом случае, я думаю, что система Python справляется с этим хорошо, у вас есть __, который вы можете использовать для доступа к частным переменным, но он дает понять, что вы возитесь с чем-то внутренним, и все же это существенно не ограничивает вас. Любой, кто хочет истинной философии дизайна ООП, просто никогда не может использовать «__» или иметь его в стиле кодирования своей компании или проекта. Может быть, вариант пометить это как ошибку было бы неплохо. Я имею в виду, что в общем утиная типизация и частные переменные действительно несовместимы. Как минимум, вы полностью испортили пространство имен, потому что теперь obj.set ("hi", 5) не работает, если "hi" является закрытым? Но это работает, если "привет" не существует? В этом нет особого смысла ... Итак, очень категорическое "против" тому, чтобы сделать приватное полностью недоступным, что бы вы ни делали, это мой голос. Очень важно, чтобы частные переменные существовали так, как это делает Python в настоящее время. Tbh Я все еще не уверен, как решить проблему с утиной типизацией с частными переменными, даже если бы хотелось иметь действительно и недоступные частные переменные. Я думаю, вы просто заблокируете obj.set и заставите его выдать ошибку. Теперь obj.set должен возвращать логическое значение, что кажется странным. Вызов is_private? Что вы должны вызывать перед каждым использованием obj.set? я не знаю

[Боже мой, можем ли мы получить фактическое обнаружение ошибок, мы говорим о частных переменных, но на данный момент, если у вас есть ошибка в gdscript, игра просто игнорирует ее (facepalm). Может быть, я делаю это неправильно, но если какой-либо мой код делает что-то незаконное, похоже, что gdscript просто возвращает null из функции, что делает его настолько трудным для отслеживания, JS когда-либо был таким плохим, а JS - это беспорядок в языке. Я знаю, что сбой игры может быть слишком большим, но мне все еще приходится просто выполнять двоичный поиск в моей кодовой базе, помещая операторы печати, пока я не найду два последовательных оператора печати, где первый печатает, а второй нет, просто чтобы выяснить, где сломался код. JS / Python на удивление намного строже в этом смысле, несмотря на то, насколько они свободны во всем остальном.]

Я предлагаю найти последовательную проектную организацию, чтобы минимизировать проблему. Вы можете использовать корневой узел сцены в качестве интерфейса для управления сценой извне, а дочерний скрипт - в качестве бэкэнда.

В качестве альтернативы вы можете использовать только методы, экспортировать переменные и сигналы и никогда не касаться простых переменных извне. Это простое соглашение, и GDScript сохраняет его простоту.

Это невозможно и в Python: даже двойное подчеркивание в начале не мешает вам получать доступ к переменным и изменять их. В Python вместо этого вы используете соглашения: один ведущий знак подчеркивания, чтобы указать, что переменная является частной, ALL_CAPS, чтобы указать, что что-то является константой ... они все еще доступны из любого места, но на практике это не проблема.

Я просто хочу сказать, что в Python можно использовать атрибут _private_.

Цитата (https://www.python.org/dev/peps/pep-0008/):

__double_leading_underscore: при именовании атрибута класса вызывает изменение имени (внутри класса FooBar, __boo становится _FooBar__boo; см. ниже).

__double_leading_and_trailing_underscore__: «волшебные» объекты или атрибуты, которые живут в пространствах имен, контролируемых пользователем. Например, __init__, __import__ или __file__. Никогда не придумывайте такие имена; используйте их только так, как указано в документации

Если вы нажмете эту ссылку и CTRL + F "частный", вы получите

Мы не используем здесь термин «частный», поскольку ни один атрибут в Python не является действительно частным (без, как правило, ненужного объема работы).

Переменные с двойным или одиночным подчеркиванием действуют так же, как обычные переменные, это просто соглашение, указывающее, что они не должны использоваться и могут измениться при обновлении библиотеки, поскольку они внутренние. В общем, поскольку питонические языки, такие как GDScript, обрабатывают объекты, как если бы они были просто словарями, было бы неудобно пытаться принудительно использовать частные переменные и заставить их использовать пространство имен.

Если вы нажмете эту ссылку и CTRL + F "частный", вы получите

Мы не используем здесь термин «частный», поскольку ни один атрибут в Python не является действительно частным (без, как правило, ненужного объема работы).

Переменные с двойным или одиночным подчеркиванием действуют так же, как обычные переменные, это просто соглашение, указывающее, что они не должны использоваться и могут измениться при обновлении библиотеки, поскольку они внутренние. В общем, поскольку питонические языки, такие как GDScript, обрабатывают объекты, как если бы они были просто словарями, было бы неудобно пытаться принудительно использовать частные переменные и заставить их использовать пространство имен.

Я согласен, они не называют это _приватным_ атрибутом. Однако позвольте мне описать, как это работает:

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

Таким образом, он не называется атрибутом _private_, но ведет себя почти так же.
Было бы здорово иметь в GDScript почти частный атрибут, как он существует в Python.

О да, я полностью с тобой согласен. Python просто дает вам синтаксический сахар для использования ._Employee__salary. Мне лично не нравится, как это делает Python, и я думаю, что это можно значительно улучшить в Godot, как я уже упоминал в своем комментарии,

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

Это чище, потому что _Employee__salary - уродливый способ скрыть имя переменной, а наличие ключевого слова private делает его похожим на обычное ООП. Более того, это блокирует возможность иметь публичную переменную зарплаты и частную переменную _salary, что было бы некрасиво и, желательно, должно быть синтаксической ошибкой, как это есть в Java. Это связано с тем, что оба будут объявлены "var salary" и "private var salary", а это явный конфликт. Другой способ подумать: «Чтобы получить доступ к частной переменной некоторого другого класса C с членом m, вы должны использовать подчеркивание, как в C._m». Затем мы могли бы сделать ошибкой объявление переменной, начинающейся с подчеркивания, т.е. сделать закрытой единственный способ ее объявления, чтобы было ясно, что делается.

Я думаю, что единственная причина, по которой python находится в менее чем желательной ситуации, заключается в том, что вверху нет объявлений для переменных, вы просто составляете переменные класса в любом из тел функций. GDScript, похоже, требует объявлений в теле класса, что позволяет легко переходить к частным объявлениям в стиле Java.

Мне не нравятся ключевые слова, которые действуют как синтаксический сахар, если они не экономят много ввода. Здесь ввод private фактически заставит вас написать больше символов, что делает его анти-ярлыком: слегка_smiling_face:

А как насчет методов? Некоторые виртуальные методы начинаются с символа подчеркивания, поэтому мы не можем использовать один символ подчеркивания, чтобы пометить их как частные. Однако мы могли бы использовать два символа подчеркивания, чтобы избежать конфликтов за счет увеличения длины. Мне также нравится идея следовать соглашениям Python, когда это имеет смысл - в этом языке какое-то время популярно «чертовщина».

Я не думаю, что цель состоит в том, чтобы рассматривать его как ярлык, вместо этого идея состоит в том, что вне класса вы используете "_" для доступа к частным переменным. Синтаксическим сахаром будет то, как это реализовано. По сути, идентично тому, как это делает python. Но вроде да, это правда, в случае с питоном синтаксический сахар позволяет сэкономить много времени на вводе текста, но это только потому, что он превращается во что-то дурацкое и длинное. Использование псевдонимов во что-то более короткое - это строго лучше, поэтому наличие более короткого псевдонима и затем отказ от синтаксического сахара из-за слишком короткого псевдонима просто сводится к тому, должны ли мы вообще поддерживать частные переменные; нам не обязательно, мы можем просто попросить пользователей добавить переменные с подчеркиванием или выбрать свое собственное соглашение. Это только для тех, кто думает о Java и C ++, которые предпочли бы написать "private var myvariable" вместо того, чтобы просто использовать "_myvariable" как частное, как соглашение, что кажется странным, если исходить из мира ООП, даже если они оба выполняют точную то же самое. Двойное подчеркивание вполне соответствовало бы синтаксису Python, поэтому я тоже за него, особенно, если _ конфликтует с другими вещами

Я бы предпочел иметь ключевое слово, которое явно определяет поведение за пределами того, что может быть неверно истолковано только как соглашение о стилях. private получает мой голос.

Добавление огня к обсуждению: соглашение о стилях Python для "закрытых" членов заключается в добавлении подчеркивания перед именем, которое _ уже_ используется gdscript для другой цели в общих методах событий, таких как _ready() , _input и _physics_process и многие другие. Они должны быть частными? Как добавление частного ключевого слова будет взаимодействовать с этими методами? Нужно ли также использовать другие ключевые слова, например protected ?

В любом случае, я полностью за соблюдение ограничительных директив _по дизайну_, а не просто позволяю пользователям определять соглашения. Но я не уверен, что члены частного класса дадут желаемое улучшение, учитывая сложность реализации. Полагаю, придется пересмотреть и весь API. У всего языка была бы совершенно другая парадигма.

Да, кто-то это уже заметил. (См. Ответ Калину) Двойное подчеркивание было бы подходящим вариантом. То же, что и Python.

Мой 2c. В Python ничто не мешает кому-либо получить доступ к членам класса, которые начинаются с _ , а также с некоторыми внутренними знаниями с __ .

Все дело в демонстрации намерений. Философия заключается в том, что мы все взрослые и можем решить, действительно ли нам нужен доступ к предположительно частным переменным или функциям. И если мы это сделаем, мы сами сможем справиться с последствиями.

@sanchopanca

1. GDScript - это не Python.
2. По вашей логике константы тоже не нужны (var CONSTANT = 1).
3. Не всем нравится использовать __ .

Я за ключевое слово private , это даже не нарушит совместимость.
Вместо этого, если сделать func и var частными с помощью _ , это изменит ситуацию для некоторых, использующих его по другим причинам (я использую _ только в параметрах функции ).

Это напоминает мне о новой функции статической типизации, и эта частная и виртуальная функция будут работать одинаково.
Это обеспечит более четкую базу кода с лучшим обнаружением ошибок, лучшим автозаполнением, а также автоматическим документированием кода.
Если кто-то прочитает ваш код, он лучше поймет, что он делает.

Мне интересно, насколько сложно будет реализовать два новых ключевых слова для команды разработчиков.
Это наверняка было бы намного проще, чем система набора текста, и это принесло бы большую пользу.
Если бы кто-то из команды разработчиков мог подсказать мне, что делать, я был бы рад помочь, если честно!

Просто чтобы добавить еще один голос за добавление частных и защищенных ключевых слов.
Если вы когда-либо писали код, который собирается использовать другой разработчик, вы не можете противостоять этому.
Все против добавления ключевого слова можете проверить эту тему:
https://softwareengineering.stackexchange.com/questions/143736/why-do-we-need-private-variables

Мы по-прежнему собираемся использовать GDscript, но почему бы не улучшить его в процессе.

_, __, ___ и т. д. - это просто глупо, так же как и добавление префиксов к именам переменных, чтобы предлагать типы
intAge, strName, bIsAlive ... все они показывают только отсутствующие языковые функции.
Таким образом, даже не сравнивая GDScript с Python или другими языками, разработчик может провести опрос, чтобы узнать, хотят или не хотят большинство этих двух ключевых слов;)

Если функция будет реализована, надеюсь, будет выбран путь C ++. Ключевое слово private или public перед каждым объявлением затрудняет чтение C #.

Мне лично не нравится способ C ++, так как у нас нет синтаксиса ввода C ++, и по умолчанию все будет общедоступным. Я имею в виду возможность установить частную переменную без добавления еще одной строки или перемещения ее на новую строку - больше, чем частое отсутствие частного ключевого слова.

private var foo : String = "foobar" больше соответствует использованию существующих ключевых слов export и onready .

Закрытие в пользу https://github.com/godotengine/godot-proposals/issues/641 , так как предложения функций теперь отслеживаются в репозитории предложений Godot.