Godot: GDScript의 개인 변수 또는 함수

변수에 가장 가까운 것은 setget 를 사용하여 아무 것도 하지 않거나 경고를 출력하는 함수로 이끄는 것입니다. 그러나 아니요, 진정한 개인 변수나 함수는 없습니다.

@YeldhamDev 슬프게도 setget 가 도움이 되지만 공공 재산을 보고 싶지 않다면 방법이 없습니다. @reduz 어떻게 생각하세요?

파이썬에서도 가능하지 않습니다. 이중 선행 밑줄조차도 변수에 액세스하고 수정하는 것을 방지하지 않습니다. Python에서는 대신 규칙을 사용합니다. 변수가 private임을 나타내는 선행 밑줄 하나, 상수임을 나타내는 ALL_CAPS... 어디에서나 여전히 액세스할 수 있지만 실제로는 문제가 되지 않습니다.

@NathanLovato 이 경우 GDScript는 Python과 달라야 합니까?

@Chaosus 비공개 변수가 필요한 이유를 설명하는 인수를 제공해야 합니다. 그렇지 않으면 누군가가 이 작업을 수행할 가능성이 거의 없습니다.

개인 변수는 데이터를 캡슐화하고 다른 클래스와의 결합을 방지하는 데 도움이 됩니다. 다른 클래스가 이러한 변수에 액세스하는 것을 방지합니다. 처음에 액세스하지 않으면 문제도 해결됩니다.

private 키워드를 사용하거나 규칙을 사용하여 작성하는 두 경우 모두 변수를 비공개로 만드는 시기와 방법, 변수에 액세스할 수 있는 시기와 방법을 배워야 합니다. 나중에 인터페이스를 손상시키지 않고 내부를 변경할 수 있도록 클래스를 디자인하는 방법을 배워야 합니다. 그것이 코드 아키텍처와 관련하여 가장 큰 문제의 원인이라고 생각합니다.

Python과 관련하여 수백만 명의 Python 개발자에게 적합합니다. 직접 액세스를 방지하는 변수를 "비공개"로 만드는 메커니즘이 있으며 간단합니다. 하나 대신 두 개의 선행 밑줄을 작성합니다. 하지만 아직 사용하는 사람을 본 적이 없습니다. 최근까지 JS에서 사용할 수 없었습니다. 아마 그런 언어가 또 있을 겁니다.

나는 그것이 GDscript에 있어서는 안 된다고 말하는 것이 아닙니다. 다른 사람들이 이 기능을 잘 사용한다면 나는 정말로 상관하지 않습니다. 나는 그것이 그렇게 유용하다고 확신하지 못합니다. 예를 들어 Godot는 자동 완성에서 선행 _ 또는 2가 있는 변수를 나열할 수 없었습니다(비록 _function_name 를 가상 함수에 대한 관례로 사용하지만)?

GDScript에서 Intellisense가 있는 내부 메서드를 보고 싶지 않고 C# 및 기타 정적 형식 언어처럼 만들고 싶습니다.

예, 구현하기 어렵고 새로운 키워드가 필요하다는 데 동의합니다. 아주 작은 결과에 너무 많은 노력이 필요합니다.
"__" 접두사가 있는 솔루션은 부분적으로 문제를 해결합니다. 덕분에 (나는 Python으로 작업한 적이 없으므로 새로운 것입니다).

나는 이것이 이미 닫혀 있고 보관되어 있다는 것을 알고 있지만(이에 대해 다른 문제가 열려야 하는지 확실하지 않음) 액세스 수정자는 모든 프로그래밍 언어에서 매우 중요한 기능입니다. Godot용 새 노드 애드온을 만들고 싶고 새 노드에 노드 외부에서 수정되어서는 안 되는 내부 상태 변수가 있는 경우, 이를 방지할 수 있는 방법은 없습니다. 이 기능을 모방하기 위해 선행 밑줄을 사용할 수 있다는 것을 이해하지만 여전히 액세스 수정자의 전체 지점인 액세스를 방지하지 못합니다. 제 생각에는 다른 사람들이 당신의 개체와 상호 작용하는 방식을 제어할 수 있는 방법이 없기 때문에 이것은 꽤 큰 문제입니다.

예, @dylmeadows에 동의합니다. 이런 식으로 유용할 것입니다.

나는 확실히 프로 개인 함수와 변수이기도합니다.

1. 예, 메서드 이름 앞에 _를 사용하는 private에 대한 규칙이 있지만 가상 기능에도 동일한 규칙이 사용됩니다. 따라서 밑줄이 표시되면 "절대로 해당 기능을 만지지 마십시오!"를 의미할 수 있습니다. 또는 "해당 기능 덮어쓰기!". 솔직히 위험합니다.

2. 혼자 또는 소규모 프로젝트에서 아주 작은 팀으로 작업하는 경우 어떤 기능이 사용되어야 하고 어떤 기능이 내부 전용인지 알고 있기 때문에 그다지 중요하지 않습니다.
   하지만 팀이 성장할수록 이것은 점점 더 어려워집니다. 사람들은 항상 스스로 작성하지 않은 클래스로 작업합니다. 저는 작업을 수행하기 위해 많은 작은 내부 함수를 작성하는 사람이기 때문에 사람들이 이러한 함수를 호출하는 것을 방지할 수 있기를 정말로 원합니다. 의도하지 않은 동작과 버그로 이어질 수 있으며 실수가 발생하면 이러한 문제를 수정하는 데 시간이 걸립니다. 결국 그들은 외부에서 호출되어 있기 때문에 일반적인 규칙에도 불구하고, 이러한 일들이 더 큰 팀에서 일어나는 것입니다.

3. 마지막으로 중요합니다. 자동 완성. 저는 수업이 무엇을 할 수 있는지 배우기 위해 이것을 많이 사용하는 사람입니다.
   그냥 '.'라고 넣었습니다. 마지막에 어떤 기능이 나타나는지 확인하십시오. 뭔가 유용하게 들리면 사용합니다.
   어쨌든 호출되지 않아야 하는 모든 함수로 복잡하지 않다면 훨씬 깨끗할 것입니다. 게다가 - 그리고 다시 - 나는 여전히 이 _name 함수가 비공개인지 가상인지 모릅니다.

또한 개인 변수는 개인 프로젝트에서도 유용할 수 있습니다. 때때로 내가 작업하고 있는 게임에서 작업할 수 없는 기간이 있어서 일부 기능이 하는 일을 잊어버리기 시작합니다. 또는 어떤 것을 사용해야 하고 어떤 것을 사용하지 말아야 하는지 잊어버렸습니다.

개인 변수는 이것으로 훌륭할 것입니다! 노드 외부에서 변수나 함수에 액세스할 수 없도록 하고 프로젝트로 돌아올 때 변수를 사용하는 방법을 추측할 수 있고 내 모든 코드를 다시 완전히 읽을 필요가 없습니다.

나는 Byteron과 dylmeadows가 말한 것 또한 두 번째입니다. 그들은 단지 자신의 게시물을 충분히 잘 썼고 내가 생각하는 것을 정확히 말했습니다. 그냥 내 두 센트를 추가하고 싶었습니다.

여러 사용자가 관심을 갖고 이에 대해 논의하기를 원하므로 다시 열겠습니다. 아직 계획은 없지만 커뮤니티에서 강한 관심이 있는지 논의하고 볼 수 있습니다.

Python은 이상적이라고 언급하는 최고의 언어가 아닙니다.
Godot는 매우 객체 지향적이라고 합니다. 모든 스크립트는 객체이기도 합니다. 객체 지향 프로그래밍의 주요 원칙 중 하나는 캡슐화를 제공하는 것입니다. 외부에서 손대지 않은 무언가를 갖고 싶다면 아마도 가장 좋은 이유일 것입니다.

저는 개인적으로 사람들이 변수를 편집하거나 함수에 액세스하는 것을 절대적 으로 방지 경우 를 본 적이 없습니다. 사람들이 자신이 무엇을 하고 있는지 알지 못하는 한 무언가를 엉망으로 만들지 말라고 말하고 싶을 때마다 이름 앞에 _ (또는 _internal_ 또는 이와 유사한 것)을 붙입니다.

나는 단순히 자동 완성에서 변수/함수를 숨기는 키워드(또는 이와 유사한 것)에 반대하지 않을 것입니다. 접근을 완전히 차단할 필요는 없다고 생각합니다.

한편으로는 금지하지 말고 경고하는 것이 좋습니다. 그러나 반면에 private 필드와 메서드는 일반적으로 여러 번 사용됩니다. 그리고 긴 변수 이름(예: _internal_variable )은 약간 성가십니다.
어떤 경우든 private 키워드가 있다고 해서 강제로 사용하는 것은 아닙니다.

클래스의 private 멤버를 상수와 같은 것으로 만듭니다. 마찬가지로 변수 이름을 BIG LETTERS로 쓰고 값을 변경하지 않는다는 데 동의할 수 있습니다. 하지만 우리는 그렇게 하지 않습니다. 즉, private 변수는 일반 변수와 상수의 교차점입니다. 이 경우에 특별한 키워드를 입력하지 않는 이유는 무엇입니까?

예, 메서드 이름 앞에 _를 사용하는 private에 대한 규칙이 있지만 가상 기능에도 동일한 규칙이 사용됩니다. 따라서 밑줄이 표시되면 "절대로 해당 기능을 만지지 마십시오!"를 의미할 수 있습니다. 또는 "해당 기능 덮어쓰기!". 솔직히 위험합니다.

이것이 제가 여기서 본 가장 큰 문제입니다. private 키워드 대신 virtual 키워드를 사용할 수 있습니까? 일부 가상 메서드는 "func"를 작성할 때 이미 자동 완성에 나타나므로 덮어써야 하는 가상 기능과 자동 완성에 나타나지 않아야 하는 개인 기능을 명시적으로 구분하는 키워드로 충분할 수 있습니다. 의 장점 virtual 키워드는 적게 이상을 사용하십시오 있다는 것입니다 private 덜 쓰기, 그래서.

개인 클래스 멤버도 포함되는 것을 보고 싶습니다. 이것이 다른 언어에 존재하는 이유가 있습니다. 다른 소비자/팀 구성원(또는 자신도)은 모든 클래스가 어떻게 작동하는지 알 필요가 없습니다. 사실, 그들은 아마도 어쨌든 내부에 있어야 할 기능을 가지고 장난을 칠 수 있는 옵션이 없어야 합니다.

나는 선행 밑줄이 이것이 개인 회원임을 "표시"해야 한다는 것을 이해하지만 실제로는 어떻게든 수정하면 작업이 완료되는지 여부는 아무도 신경 쓰지 않습니다. 플러그인으로 일부를 사용하고 모든 사람이 원하는 대로 변경할 수 있는 경우 특히 고통스럽습니다. 내가 만드는 모든 개체/스크립트의 상태를 완전히 제어하고 싶습니다. 누군가가 원할 때마다 상태의 모든 측면을 변경할 수 있는 개체를 갖는 것은 짜증나는 것보다 다른 사람들이 소비할 수 있는 코드를 생성하게 만듭니다.

그 외에도 "사용 가능한" 변수/함수 목록을 정리하는 것이 좋습니다.

개발자 팀에 한 가지 추천할 수 있습니까? 그런 다음 이 모든 것을 고려하십시오. 자동 완성 목록 순서를 변경합니다. 문자나 숫자로 시작하지 않는 var 또는 func는 자동 완성 목록의 __Bottom__에 나타납니다. 그런 다음 항목을 보려면 _를 입력해야 합니다. 또한 이름에 수학이 아닌 다른 기호나 논리 기호를 사용할 수 있다면 더 좋겠죠? 아직 시도하지 않았지만 €Display 또는 ¥Print가 허용되는 함수 이름입니까? 등.

또한 이름에 수학이 아닌 다른 기호나 논리 기호를 사용할 수 있다면 좋겠죠? 아직 시도하지 않았지만 €Display 또는 ¥Print가 허용되는 함수 이름입니까? 등.

https://github.com/godotengine/godot/issues/24785를 참조

그래서 이것저것 만지작거리다가 아무 작업도 하지 않는 setter를 정의하면 다른 스크립트에서 동일한 변수에 새 값을 할당하고 인쇄하려고 해도 원래 값은 다음과 같다는 결론에 도달했습니다. 인쇄. 정말 사적인 건 아니지만, 충분히 가깝다고 생각합니다...

공개로 표시되고 방금 수정한 변수가 변경되지 않았다는 힌트가 전혀 없다는 의미입니까?
이 방법을 광범위하게 사용하는 디버깅 코드를 재미있게 즐기십시오.

빈 setter 대신 오류를 인쇄할 수도 있습니다.

나는 프로그램을 실행하고 실제로 그 코드 줄을 적중했을 때 하지 말아야 할 일을 했다는 것을 여전히 알고 있습니다. 코드를 작성하는 동안 여전히 공개된 것으로 보이며 단일 개인 변수를 설정하려면 여러 줄의 코드가 필요합니다.
퍼팅 private 그 변수의 앞에이 방법은 짧은 코드의 추가 라인을 필요로하지 않으며, 내가 입력 할 때 거짓 권리를 액세스 나를 막을 것입니다.

GDScript는 동적 언어라는 사실에도 불구하고 나에게 상당히 C++처럼 느껴집니다. C++로 코드 작성에서 GDScript로 전환할 때 액세스 수정자가 그리워집니다. 즉, GDScript는 실제로 OOP에 대한 완전한 지원이 없습니다.

나는 이 문제만 훑어보았지만, 이름 앞에 밑줄이 붙은 함수와 변수를 자동 완성에서 숨길 수 있다면 좋을 것입니다. 나는 그것이 가상 기능인지 여부를 결정하고 따라서 아마도 관계없이 나타나야 할 것입니다.

밑줄은 가상 기능에도 사용되며 가상 기능도 공개하려는 경우가 분명히 있습니다.

다른 노드/객체에서만 밑줄 접두사가 붙은 함수를 숨길 수 있지만 self/base에 대한 호출에 대해서는 표시합니다.

내 제안은 가상 기능에 단일 밑줄을 사용하고 "비공개" 기능에 이중 선행 밑줄을 사용하는 것입니다. 이런 식으로 가상 기능에 영향을 주지 않고 자동 완성에서 숨길 수 있습니다.

변수를 숨기기 위해 밑줄을 사용하는 것은 좋지 않습니다. 변수의 액세스 _attribute_를 변경할 때 _name_을 변경해야 하기 때문입니다. 사실 variable 와 _variable 는 다른 이름입니다.
이것은 또한 UNIX 파일 이름의 점과도 같습니다. 상당히 논쟁의 여지가 있는 결정입니다.

여기 내 의견이 있습니다

• 비공개 함수의 경우 접두사 "__"
• "__"가 있는 함수는 자동 완성에 표시되지 않습니다.
• "private func x()"는 "func __x()"의 구문 설탕입니다.

위는 "__" 접두사가 있는 변수를 포함하는 모든 코드를 중단합니다. 그러나 그것을 제외하고는 그 시스템이 이상적이라고 생각합니다.

지금까지 GDScript의 기능은 Python/JS와 매우 유사하며 이 두 언어 모두 매우 좋은 이유로 개인 변수와 함수가 없습니다. 이는 그들의 디자인 철학과 완전히 반대입니다. 당신에게는 자유가 있고 그 자유는 중요합니다. 그것이 바로 코딩을 쉽게 만드는 것입니다. 캡슐화를 희생하지만 그것이 그들의 철학입니다. 진정한 캡슐화는 [모든 유형을 직접 확인하지 않는 한] 유형 검사 없이 이미 깨졌습니다. 따라서 엄격한 유형 지정을 구현하지 않는 한 개인 변수는 잘못된 것으로 느껴집니다. OOP의 그래디언트에서 엄격한 유형 지정은 개인 변수보다 먼저 옵니다. 엄밀한 타이핑이 있는 언어는 많지만 개인 변수가 없는 언어는 많지만 개인 변수가 있고 엄밀한 타이핑이 없는 언어는 없습니다. 이것은 정당한 이유가 있습니다. 그 외에도 JS는 전체 상속 트리에 대한 액세스를 제공하고 이러한 측면도 변경할 수 있습니다. 개체가 있는 코드를 사용하여 런타임 중에 개체가 상속하는 클래스를 변경할 수 있습니다! 물론 그런 일이 일어나지는 않지만 디자인 철학을 보여줍니다.

따라서 제 생각에는 진정한 개인 변수가 언어를 크게 방해할 것입니다. 어쨌든, 나는 파이썬의 시스템이 그것을 잘 한다고 생각합니다. 당신은 개인 변수에 접근하는 데 사용할 수 있는 __이 있지만, 당신이 내부적인 것을 엉망으로 만들고 있다는 것을 분명히 하지만 의미 있게 제한하지는 않습니다. 진정한 OOP 디자인 철학을 원하는 사람은 단순히 "__"를 사용하거나 회사 또는 프로젝트의 코딩 스타일에 사용할 수 없습니다. 아마도 그것을 오류로 표시하는 옵션이 좋을 것입니다. 내 말은 일반적으로 오리 타이핑과 개인 변수는 실제로 함께 가지 않는다는 것입니다. 최소한 "hi"가 비공개인 경우 obj.set("hi", 5)가 작동하지 않기 때문에 최소한 네임스페이스를 완전히 망쳐야 합니다. 그러나 "hi"가 없으면 작동합니까? 그것은 별로 말이 되지 않습니다... 그래서, 당신이 무엇을 하든 private를 완전히 액세스할 수 없도록 강요하는 것에 대해 매우 강한 반대, 그것이 제 투표입니다. Python이 현재 수행하는 방식으로 개인 변수가 존재하는 것은 매우 강력합니다. Tbh 진정으로 액세스할 수 없는 개인 변수를 갖고 싶어하는 경우에도 개인 변수로 오리 타이핑 문제를 해결하는 방법을 여전히 잘 모르겠습니다. obj.set을 차단하고 오류를 던지게 만든 것 같습니다. 이제 obj.set은 부울 값을 반환해야 합니다. 이상하게 보입니다. is_private 호출? obj.set을 사용할 때마다 호출해야 합니까? 이크

[맙소사, 우리는 실제 오류 감지를 얻을 수 있습니까? 우리는 개인 변수에 대해 이야기하고 있지만 현재로서는 gdscript에 버그가 있으면 게임에서 조용히 무시합니다(facepalm). 어쩌면 내가 잘못하고있는 것일 수도 있지만 내 코드가 불법적 인 작업을 수행하는 경우 gdscript가 함수에서 null을 반환하여 추적하기가 너무 어려워 JS는 그 정도로 나빴고 JS는 언어의 엉망입니다. 게임 충돌이 너무 많다는 것을 알고 있지만 전자가 인쇄되고 후자가 인쇄되지 않는 두 개의 연속적인 인쇄 명령문을 찾을 때까지 인쇄 명령문을 넣어 코드베이스를 이진 검색해야 합니다. JS/Python은 다른 모든 면에서 얼마나 자유롭지만 그런 면에서 놀라울 정도로 훨씬 더 엄격합니다.]

문제를 최소화하기 위해 일관된 프로젝트 조직을 찾는 것이 좋습니다. 장면의 루트 노드를 인터페이스로 사용하여 외부에서 장면을 제어하고 자식 스크립트를 백엔드로 사용할 수 있습니다.

또는 메서드만 사용하고 변수 및 신호를 내보낼 수 있으며 외부에서 간단한 변수는 절대 건드리지 않습니다. 이것은 간단한 규칙이며 GDScript는 단순함을 유지할 수 있습니다.

파이썬에서도 가능하지 않습니다. 이중 선행 밑줄조차도 변수에 액세스하고 수정하는 것을 방지하지 않습니다. Python에서는 대신 규칙을 사용합니다. 변수가 private임을 나타내는 선행 밑줄 하나, 상수임을 나타내는 ALL_CAPS... 어디에서나 여전히 액세스할 수 있지만 실제로는 문제가 되지 않습니다.

나는 단지 파이썬에서 _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 "비공개"를 클릭하면

여기서 "비공개(private)"라는 용어를 사용하지 않습니다. 왜냐하면 파이썬에서는 어떤 속성도 실제로 사적인 것이 아니기 때문입니다(일반적으로 불필요한 양의 작업 없이).

이중 밑줄 또는 단일 밑줄 변수는 일반 변수처럼 작동합니다. 사용해서는 안 되며 내부 변수이기 때문에 라이브러리를 업데이트할 때 변경될 수 있음을 참조하는 규칙일 뿐입니다. 일반적으로 GDScript와 같은 파이썬 언어는 객체를 사전인 것처럼 취급하기 때문에 개인 변수를 강제로 적용하여 네임스페이스를 사용하도록 하는 것은 어색할 것입니다.

해당 링크를 클릭하고 CTRL+F "비공개"를 클릭하면

여기서 "비공개(private)"라는 용어를 사용하지 않습니다. 왜냐하면 파이썬에서는 어떤 속성도 실제로 사적인 것이 아니기 때문입니다(일반적으로 불필요한 양의 작업 없이).

이중 밑줄 또는 단일 밑줄 변수는 일반 변수처럼 작동합니다. 사용해서는 안 되며 내부 변수이기 때문에 라이브러리를 업데이트할 때 변경될 수 있음을 참조하는 규칙일 뿐입니다. 일반적으로 GDScript와 같은 파이썬 언어는 객체를 사전인 것처럼 취급하기 때문에 개인 변수를 강제로 적용하여 네임스페이스를 사용하도록 하는 것은 어색할 것입니다.

동의합니다. 그들은 그것을 _private_ 속성이라고 부르지 않습니다. 그러나 작동 방식을 설명하겠습니다.

# 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_ 속성이라고 하지 않지만 거의 비슷하게 동작합니다.
Python에 존재하는 것처럼 GDScript에 거의 private 속성을 갖는 것이 좋을 것입니다.

아, 네, 전적으로 동의합니다. Python은 단순히 ._Employee__salary를 사용하기 위한 문법적 설탕을 제공합니다. 나는 개인적으로 python이 하는 방식을 좋아하지 않으며 내 의견에서 언급했듯이 Godot에서 강력하게 개선될 수 있다고 생각합니다.

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

_Employee__salary는 변수 이름을 숨기는 추악한 방법이고 private 키워드를 사용하면 일반 OOP처럼 만들기 때문에 더 깨끗합니다. 더 나아가 이것은 공개 변수 급여와 개인 변수 _salary를 가질 수 있는 기능을 차단합니다. 이는 보기 흉하고 바람직하게는 Java에서처럼 구문 오류가 되어야 합니다. 이는 둘 다 "var 급여"와 "private var 급여"로 선언되어 명백한 충돌이기 때문입니다. 생각할 수 있는 또 다른 방법은 "멤버 m이 있는 다른 클래스 C의 개인 변수에 액세스하려면 C._m에서와 같이 밑줄을 사용해야 합니다"입니다. 그런 다음 밑줄로 시작하는 변수를 선언하는 것을 오류로 만들 수 있습니다. 즉, 변수를 선언하는 유일한 방법을 private로 만들어 수행 중인 작업을 명확하게 할 수 있습니다.

python이 rn보다 덜 바람직한 상황을 갖는 유일한 이유는 변수에 대한 선언이 맨 위에 없고 함수 본문에서 클래스 변수를 구성하기 때문입니다. GDScript는 클래스 본문에 선언을 요구하는 것으로 보이며 Java와 같은 개인 선언으로 쉽게 분리됩니다.

나는 많은 타이핑을 저장하지 않는 한 구문 설탕으로 작동하는 키워드를 좋아하지 않습니다. 여기에 private 하면 실제로 더 많은 문자를 작성하게 되어 바로 가기 방지가 됩니다. :slightly_smiling_face:

또한 방법은 어떻습니까? 여러 가상 메서드는 밑줄로 시작하므로 단일 밑줄을 사용하여 비공개로 표시할 수 없습니다. 하지만 두 개의 밑줄을 사용할 수 있습니다. 그러면 더 길어지는 대신 충돌을 피할 수 있습니다. 또한 이해가 될 때 Python 규칙을 따르는 아이디어를 좋아합니다. "dunder"는 해당 언어에서 한동안 인기가 있었습니다.

나는 그것을 지름길로 보는 것이 의도라고 생각하지 않습니다. 대신 아이디어는 클래스 외부에서 "_"를 사용하여 개인 변수에 액세스한다는 것입니다. 구문 설탕은 구현 방법입니다. 본질적으로 파이썬이 수행하는 방식과 동일합니다. 그러나 예, 그렇습니다. 파이썬의 경우 구문 설탕이 많은 타이핑을 절약하지만 그것은 단지 어리석은 긴 것으로 별칭이 지정되기 때문입니다. 더 짧은 것으로 앨리어싱하는 것이 더 낫습니다. 따라서 더 짧은 별칭을 사용하고 별칭이 너무 짧기 때문에 해당 구문 설탕을 사용하지 않기로 선택하는 것은 개인 변수를 전혀 지원해야 하는지 여부로 귀결됩니다. 그럴 필요는 없습니다. 사용자가 변수 앞에 밑줄을 추가하거나 고유한 규칙을 선택하도록 할 수 있습니다. 그것은 단지 "_myvariable"을 관례로 비공개로 사용하는 것보다 오히려 "private var myvariable"을 작성하려는 Java 및 C++ 마인드를 위한 것입니다. OOP 세계에서 올 때 둘 다 정확한 것을 달성하더라도 이상하게 느껴지는 것입니다. 같은 것. 이중 밑줄은 Python의 구문과 매우 잘 일치하므로 저도 그 중 하나를 선택합니다. 특히 if _ 가 다른 항목과 충돌하는 경우

나는 오히려 스타일 규칙으로 잘못 해석될 수 있는 것 이외의 동작을 명시적으로 정의하는 키워드를 갖고 싶습니다. private 이 내 투표를 얻습니다.

토론에 불을 더하기: "비공개" 멤버에 대한 파이썬 스타일 지정 규칙은 이름 앞에 밑줄을 추가하는 것입니다. 이 밑줄은 _ready() , _input 와 같은 일반적인 이벤트 메서드에서 다른 목적으로 gdscript에 의해 _이미_ 사용됩니다. _physics_process , 몇 가지를 예로 들 수 있습니다. 그것들은 비공개라고 해야 합니까? private 키워드를 추가하면 이러한 방법과 어떻게 상호 작용합니까? protected 같은 다른 키워드도 구현해야 합니까?

어쨌든 저는 사용자가 규약을 정의하도록 하는 것보다 _디자인에 의해_ 제한적인 지시문을 시행하는 데 찬성합니다. 그러나 구현의 복잡성을 감안할 때 private 클래스 멤버가 의도한 개선을 제공할지 확신할 수 없습니다. 전체 API도 다시 방문해야 한다고 생각합니다. 전체 언어는 완전히 다른 패러다임을 가질 것입니다.

예, 누군가 이미 지적했습니다. (Calinou의 응답 참조) 이중 밑줄이 올바른 방법입니다. 파이썬도 마찬가지입니다.

내 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 키워드를 많이 보지 않는 것보다 다른 줄을 추가하거나 새 줄로 이동하지 않고 변수를 private로 설정할 수 있는 것을 더 중요하게 생각합니다.

private var foo : String = "foobar" 는 기존 export 및 onready 키워드의 사용과도 일치합니다.

기능 제안이 이제 Godot 제안 저장소에서 추적되기 때문에 https://github.com/godotengine/godot-proposals/issues/641 을 위해 마감합니다.