Godot: GDScript에서 선택적 입력

하실 수 있을 것 같습니다

func myfunction(something = InputEvent):

아무 것도 전달하지 않으면 빈 입력 이벤트를 제공하지만 변수가 해당 유형이 되도록 강제하지는 않습니다.

myfunction('string')

잘 작동합니다.

로드맵에 있습니다 :)
https://github.com/godotengine/roadmap/blob/master/ROADMAP.md

@힌스바트
어떻게 생겼는지 또는 GDScript의 다른 부분과 어떻게 작동하는지에 대한 참조가 있습니까? 아니면 로드맵에 있는 아이디어에 불과합니까?

불행히도 아니오, 일부 irc 토론 외에 아직 이에 대한 참조가 없습니다.

CC @reduz , 이에 대해 그가 염두에 두고 있는 것에 대한 힌트를 제공합니다.

@LeonardMeagher2 는 당신이 쓴 것과

이건 어떤가요:

func myfunction(something is InputEvent, something_else is String):

그것은 나에게 꽤 좋으며 is 키워드를 더 유용하게 만들고 코드를 이해하기 쉽게 만듭니다.

나는 동의하지 않는다. String something 또는 something : String 중 하나를 사용하면 됩니다. something is String 은(는) 나쁘게 보입니다.

String something 또는 something is String 둘 다 괜찮습니다. 콜론을 사용하면 코드에서 많은 콜론 기호를 만들 수 있다고 생각합니다.

is 가 사용되지 않는다면 다른 언어의 이 표기법에 익숙하고 더 일반적이라고 생각하기 때문에 String something 선호합니다.

@neikeq
var something:String = " " 와 같이 var를 생성할 때도 유형을 선언할 수 있다면 동의할 것입니다.

그렇지 않으면 그냥 함수 정의에서 세미콜론을 사용하는 것이 더 혼란스러울 것입니다.

"Is"는 지금 gdscript에서 상속에 대해 묻는 데 사용되는데 왜 필요하지 않습니까?

C와 같은 유형 접두사가 더 나은 IMO입니다. 더 짧고 빠르게 입력할 수 있으며 유형을 사용할 때 var 또는 func를 대체할 수 있습니다.

예시:

int some_variable

int some_function(int some_argument):
    return some_variable + some_argument

그것에 대한 나의 투표.

@juan-garcia-m
나는 그것이 타이핑과 같은 c에 익숙하지 않은 사람에게 더 이해하기 쉽다고 생각하지 않습니다. 타이핑하기는 쉽지만 가독성은 훨씬 떨어진다고 생각합니다.
나는 함수나 변수가 무엇인지 한 눈에 파악하는 것을 선호하며 해당 키워드를 유형으로 바꾸면 해당 기능이 제거됩니다. 제가 C와 C++에 입문하기 어려운 이유 중 하나입니다.

분명히 그 언어는 나를 위해 만들어질 수 없지만, 나는 이런 느낌을 받는 유일한 사람이 아닐 것이라고 확신합니다.

"is"의 한 가지 문제는 현재 3.0에서 "extens"였던 것에 대해 사용됩니다. 즉, 노드가 클래스에 속하는지 확인합니다.

@Zireael07
그렇기 때문에 함수 선언에서 유형을 확인하는 것이 적절해 보입니다.
Extends는 여전히 스크립트 상단에서 사용되지만 유형 검사를 위해 "is"가 사용됩니다(그리고 리터럴의 경우 typeof라고 생각합니다).

C 스타일 접두사는 일반적으로 더 복잡하며 이러한 유형의 언어에 대한 표준은 변수인 것 같습니다.

이게 왜 닫혔지? 아직 구현이 안되어...

그냥 토론이라 닫았는데 원하는 기능의 진행 상황을 추적하기 위해 다시 열겠습니다

C 스타일 접두사가 재고되기를 정말로 바랍니다. Typescript에 대한 내 경험에 따르면 변수를 초기화할 때 생산성이 떨어지고 개인적으로 코드 가독성이 떨어지는 것처럼 느껴집니다. 이걸 써야하나...

var foo: String = 'bar'

... var 키워드를 유형으로 바꾸는 대신...

String foo = 'bar'

...나를 미치게 해. 나는 이것이 매우 작고 까다롭게 들린다는 것을 알고 있지만, 장기적으로 게임에서 작업하면 필요한 것보다 훨씬 더 많은 키 입력이 발생합니다.

다음과 같이 표시됩니다.

Python 구문을 따릅니다(TypeScript 및 Haxe와도 유사).

이것은 꽤 의견이 있습니다. 예를 들어, 저는 많은 TypeScript 코드를 작성했으며 구문이 정말 마음에 들었습니다. 탭 대 공백과 마찬가지로 모든 사람은 일반적으로 배경과 관련하여 무엇이 가장 좋은지에 대한 자신의 의견을 가질 것입니다. var 를 보는 것이 더 쉽고 String 를 보고 그것이 함수인지 변수인지 알지 못하는 대신 변수라는 것을 알고 있습니다. 나는 "빠른 타이핑"을 좋은 논거로 보지 않고, "실수하기 더 어렵다", "읽기 쉬움"이 훨씬 더 낫다고 생각하지 않습니다(여전히 의견에 따라 달라질 수 있음).

Python 방식의 또 다른 요점은 구문 분석이 훨씬 쉽습니다. 현재 파서는 이것을 수용하기 위해 많이 변경할 필요가 없습니다. 접두사 유형의 경우 수행할 작업을 결정하기 위해 컨텍스트에 대해 더 많은 것을 고려해야 합니다.

네, 코드 가독성은 매우 주관적입니다. C 스타일 구문으로 어떻게 생겼는지 예제를 다시 작성했습니다. _I_ 아래 코드가 더 읽기 쉽고 변수와 함수를 구별하는 데 문제가 없습니다.

extends Node

const int MY_CONSTANT = 0
String my_member_variable = "Value"

void my_empty_func():
    pass

float my_other_func(bool arg1, Node2D arg2, bool default = false):
    Vector2 local_variable
    int other_variable = 0

    return float(other_variable)

개발자 생산성에 직접적인 영향을 미치기 때문에 "빠른 입력"이 좋은 주장이 아니라는 데 동의하지 않습니다. Python 스타일은 C보다 읽고 쓰기가 약간 더 복잡합니다. 이제 반환 유형을 정의하기 위해 -> 를 입력해야 합니다. Python 스타일 구문에 대해 내가 볼 수 있는 유일한 인수는 1. Python에 익숙한 사람들에게 더 어필하기 위함이고 2. 구현하기 더 쉽고 둘 다 특별히 좋은 인수라고 생각하지 않기 때문입니다. 나는 그것이 구현하기 쉬운 일이라고 제안하는 것이 아니라 그것이 더 어렵고 내 기술 수준을 넘어설 가능성이 높다고 확신하지만 장기적으로는 가치가 있다고 생각합니다.

어쨌든, 그것은 단지 내 두 페니의 가치입니다 : 미소 :. 저는 지금까지 GDScript로 개발하는 것을 즐기고 있으며 사운드 유형 시스템을 갖기를 기대하고 있습니다.

Python은 이미 이것을 지원하므로 우리가 할 수 있는 최선은 거기에서 복사하는 것입니다.

var 키워드를 싫어하는 사람들을 위해 이와 같은 것을 허용하는 구문과 같은 Nim을 추가하는 것이 가능할 수 있습니다.

  a:int
  b:float
  c:char

const
  PI:float = 3.1416
  MAX:int = 100

반환 유형이 필요한 이유가 궁금합니다. 반환하고 해당 출력이 특정 유형의 변수로 이동하고 일치하지 않으면 throw됩니다.
나는 당신이 당신의 코드를 실행하기 전에 당신을 위해 그 실수를 찾을 수 있는 편집자의 능력을 얻을 것이라고 생각합니다.

반환 유형 void 는 나에게 별로 의미가 없습니다. 이 경우 반환 유형 정의를 생략하는 것이 더 쉬울 것이라고 생각합니다.

마지막으로 -> 는 반환 유형이 있으면 이상해 보이지만 func somefunc(): String: (아마도?) 같은 nim 같은 작업을 수행하지 않을 수도 있지만 저는 그렇지 않습니다. 구문과 같은 화살표의 팬은 나에게 많은 것을 나타내지 않기 때문에 방향성을 보이지만 그와는 아무 관련이 없습니다. 비트 단위 연산 >> 및 << 생각나게 하지만 면에서 방향성이 있다.

__문제를 종료하려는 의도가 아님__

이제 노드, 해당 변수 및 반환 유형에 대한 모든 함수를 읽을 수 있으므로 반환 유형이 중요한 것으로 알려진 경우를 볼 수 있습니다.

지금은 별로 말이 되지 않을 수도 있지만 사람들은 작동 방식에 있어 매우 동적인 플러그인과 게임 코드를 작성할 수 있을 것입니다. IE, 플러그인에는 다음과 같은 경고 메시지가 있을 수 있습니다. "이 노드에는 x 반환 유형의 함수가 필요하지만 참조하려는 노드에는 필요한 메서드 서명이 있는 메서드가 없습니다."

저는 사용자 친화성을 위해 (System.Reflection을 통해) 이러한 유형의 항목을 꽤 많이 사용하는 AI Behavior라는 Unity용 플러그인을 작성했습니다. 말 그대로 사용 가능한 메서드 이름으로 채우고 올바른 서명이 있는 모든 메서드를 기반으로 콜백으로 사용할 메서드를 선택하도록 하는 드롭다운 메뉴가 있습니다. 그런 다음 게임이 실행될 때 다음에서 호출되는 메서드입니다. 위해 만들어진 상황입니다. 액세스하려는 개체/스크립트에 메서드가 없으면 검사기에 샘플 코드가 표시되므로 코드를 복사/붙여넣기하고 클래스 이름을 변경하여 스크립트를 만들 수 있습니다. :)

그래서, 제 생각에는 가능한 한 많은 스크립트 정보를 가질 수 있다는 것이 플러그인 작성자를 위해 Godot를 훨씬 더 확장 가능하게 만들 것입니다.

또한 TypeScript 스타일 구문( var name: String = "Godot" )이 동적 언어에 추가된 선택적 입력에 대한 표준 구문이 되었기 때문에 바람직하다고 생각합니다.

또한 다음과 같은 파이썬 구문을 사용하는 것이 좋습니다.
https://www.python.org/dev/peps/pep-0484/
https://docs.python.org/3/library/typing.html

이것은 선택적 타이핑을 통해 유사한 동적 언어에서 GDScript로 오는 사람들을 도울 것입니다.

BTW, 언제/어떤 릴리스에서 구현될 것으로 예상합니까? 언급된 3.1을 본 적이 있습니까?

이것은 Godot 3.1에서 사용 가능해야 합니다.

C 스타일 접두사에 대한 인수가 더 복잡하거나 이해하기 쉬우며 읽기 쉽고 파이썬 구문 또는 이와 유사한 것을 사용하는 것이 더 환영합니다. 예를 들어, 카메라 페이지에서 정말 빨리 빼내려고 set_orthogonal ( float size, float z_near, float z_far ) 처음에는 저 스스로도 잘 이해하지 못했습니다. 그러나 제 생각에 배우는 데에는 정말 시간이 걸렸고, 그 후에는 완전히 이해가 되었습니다.

안녕하세요, 제안입니다.

이론적 해석:
정적 타이핑이 필요하다고 생각하지만 가능하면 사용자가 유형을 지정하도록 하는 것은 피하고 싶습니다.
모든 주요 컴파일 언어는 정적 유형 추론으로 이동하고 있습니다.
@reduz 가 Godot 소스 코드에 대한 유형 추론을 좋아하지
구현이 더 복잡한지 확실하지 않습니다.
이것은 대수 데이터 유형으로 몇 가지 추가 costruct가 필요합니다.
이 원칙을 사용하는 언어가 있습니다.

https://crystal-lang.org/docs/

이전 버전과의 호환성을 유지하려면 함수와 변수를 정의하는 데 몇 가지 새로운 키워드가 필요합니다. 또는 정적 유형 검사를 활성화/비활성화하는 마법의 주석이 있을 수 있습니다.

다음은 이런 종류의 시스템이 무엇을 할 수 있는지에 대한 예입니다(루비를 조금 아는 사람들을 위해)

def test(x)
    return true if x
    return "This is false"
end

puts test(false).upcase
puts test(true)

산출:

Error in test.cr:6: undefined method 'upcase' for Bool (compile-time type is (Bool | String))

puts test(false).upcase
                 ^~~~~~

생각?

특히 코드 완성뿐만 아니라 편집 시 존재하지 않는 속성/메서드 및 잘못된 인수 수를 확인하기 위해 형식 유추를 개선하고 싶습니다. 이 부분은 선택적 입력이 완료된 후 두 번째 단계라고 생각하기 때문에 지금은 이에 대해 초조해하지 않습니다.

@m4nu3lf 의 예제는 꽤 멀리 진행됩니다. 실제로 분기를 기반으로 결과 유형을 유추하고 있습니다. 상당히 복잡해질 수 있는 코드 실행을 시뮬레이션하지 않고는 이것이 어떻게 수행되는지 알 수 없습니다. @reduz 가 가고 싶어하는지 잘 모르겠습니다.

Godot는 매우 엄격한 유형 시스템을 가지고 있지만 모든 변수는 Variant입니다(즉, 모든 유형을 저장할 수 있음). 이것은 호환성을 깨기 위한 것이 아니므로 그대로 유지해야 합니다. 따라서 var value = 42 하면 변수가 정수라고 자동으로 가정하지 않습니다. 특히 외부 스크립트에서 마음대로 설정할 수 있는 클래스 수준 변수의 경우에는 더욱 그렇습니다. 이는 유형 추론이 할 수 있는 일을 방해합니다(완결 목적으로 이와 같이 사용할 수 있음).

언급한 바와 같이 한 가지 가능성은 이것을 선택 사항으로 만드는 것입니다. 스크립트별로 활성화/비활성화되는 가치가 별로 없기 때문에 프로젝트 설정일 수 있습니다. 그러나 그것은 다음 단계에서 생각해야 할 별도의 제안입니다.

@vnen 이론적으로 'auto' 또는 'let'과 같은 매개변수/반환 유형/변수에 대한 몇 가지 새로운 키워드를 사용하고 동일한 crystal-lang 알고리즘을 사용하면 컴파일 시간에 유형을 유추할 수 있습니다.
전체 형식 유추를 사용하는 정적 입력입니다.
가지고 있다고 가정 해 봅시다.
auto my_field = 42 스크립트에서 유형을 int 추론하고 기본 변형을 int로만 제한할 수 있습니다.

그러나 그 언어는 단순한 변수 이상입니다. 분기에 따라 유형을 유형의 하위 집합으로 제한할 수 있습니다.
위의 예와 같이 반환 유형은 String 또는 Bool만 될 수 있습니다.
그러나 이것을 하기 위해서는 반드시

• 인수 유형의 새로운 조합에 대한 함수를 인스턴스화하고 각 반환 표현식에 대한 내부 유형을 유추하고 가능한 반환 유형 목록을 반환 값의 유형으로 저장합니다.
• 분기의 경우 주어진 시간에 변수의 모든 가능한 유형을 추론하기 위해 변수가 할당된 가능한 모든 분기를 노출합니다. 언제든지 변형 유형을 다음 유형으로 제한합니다.

또한 "instanceof" 조건 등을 확인해야 합니다.

if my_var instanceof MyClass:
...

그러면 if 조건의 본문에서 my_var는 'MyClass'만 될 수 있으므로 유형이 훨씬 더 제한됩니다.
이점을 얻으려면 가능한 모든 유형에서 이름이 공유되는 메서드 또는 액세스 필드만 호출할 수 있어야 합니다.
그래서 말하자

auto x = MyClass.new()
if (...):
   x = "hi"

그런 다음 이 x는 MyClass 또는 String입니다. 런타임 오류를 피하기 위해 둘 다에 공통적인 메서드만 호출할 수 있습니다.

나는 이것이 내가 원래 생각했던 것보다 훨씬 더 많은 작업이라고 생각합니다.
그래서 나는 이것으로 돌아가고 싶다. 미래에 구현될 수도 있고 누군가 crystal-lang에 대한 바인딩을 작성하기를 바랄 수도 있습니다.
어쨌든 정말 멋진 기능인 것 같아요

@m4nu3lf 귀하의 요청이 무엇인지 이해합니다. TypeScript는 매우 유사합니다(이는 제가 더 친숙한 언어입니다).

그러나 GDScript에 대해 고려해야 할 몇 가지 문제가 있습니다.

• 첫째, 그것을 구현하는 것은 쉽지 않습니다. 다른 언어가 어떻게 되는지 볼 수 있지만 여전히 오랜 시간이 걸릴 것입니다. 그래서 한 발짝 더 나아가서 나중에 생각해보고 싶다. TypeScript는 Turbo Pascal과 C#을 만든 사람과 같은 사람이 만들었기 때문에 거기에는 내가 갖지 못한 많은 경험이 있습니다.
• GDScript는 한 번에 하나의 파일로 컴파일됩니다. Crystal과 TypeScript는 모두 사용하기 전에 전체 프로젝트를 컴파일해야 합니다. 즉, 다른 스크립트 및 싱글톤과의 상호 작용을 확인하는 것이 약간 흐립니다.
• 장면 나무입니다. get_node() (많이 사용됨)를 사용하면 얻을 수 있는 노드 유형을 아는 것이 불가능합니다. Node 라는 것만 알지만 모든 하위 유형이 될 수 있습니다. load() 를 호출할 때 리소스에도 동일하게 적용되며, 특히 동적 이름으로 호출하는 경우에는 더욱 그렇습니다. _input(event) event 는 모든 InputEvent 하위 유형이 될 수 있으므로 _input(event) 에도 동일한 문제가 있습니다.

if my_var instanceof MyClass:
    ...

이것은 코드 완성을 위해 이미 추론되었습니다. 실제 유형 검사에 재사용할 수 있습니다. 특히 이 경우는 사소하지만 상당히 관련될 수 있습니다. 예를 들어 if some value == 42 and my_var is Sprite 두 번째 조건을 추가하면 코드 완성이 더 이상 작동하지 않습니다.

나는 또한 사용자의 피드백을 듣고 싶기 때문에 긴 기다림 끝에 모든 것을 완벽하게 만드는 것보다 빨리 사용할 수 있는 것이 더 중요합니다.

요약: 유형 추론을 개선하고 싶지만 조금씩 개선하면서 단계적으로 이루어져야 합니다. 선택적 입력을 사용할 수 있게 되면 나머지는 오르막입니다.

폐쇄된 이유는 무엇입니까?

좀 잘못 읽었어, 내 나쁜.

접두사와 접미사로 돌아가기: UML과 Kotlin은 모두 ": type"을 사용합니다.
Basic도 "DIM as INT"를 수행했습니다(":" 또는 "is" 대신 "as" 사용).

@programaths 오랜 시간이

이걸 닫아야 하나?

@LeonardMeagher2 내 PR이 병합되면 자동으로 닫힙니다.

@bojidar-bg 접미사 자체가 흥미롭기 때문에 접미사가 사용되는 곳을 몇 군데 추가하고 싶었습니다. UML은 분석과 비기술적인 사람들을 위한 것이기도 합니다. Kotlin은 "효과적인 Java"를 구현하면서 Java보다 더 편안하고 현대적으로 개발된 언어입니다.

따라서 접미사를 선택한 이유를 기록해야 하는 경우에도 포함될 수 있습니다. 때때로 사람들은 이유를 갖고 싶어하고 사용자와 관련이 없는 한 기술적인 이유를 쉽게 무시합니다.
(예: "파서는 모호성을 조기에 해결할 수 있고 속도가 100배 빨라짐을 의미하는 동일한 프로그램을 더 빠르게 컴파일할 수 있고 더 많은 테스트를 허용함)

항상 재료가 있어야 좋죠? ;-)