Godot: GDScript: 가변 함수(가변 인수/변수 수)

내가 이것을 올바르게 이해하고 있기 때문에 우리는 ruby의 splat operator 와 같은 것을 말하고 있습니까?

지난번에 내가 gdscript에 대해 무언가를 제안했을 때 reduz에 의해 매우 빨리 종료되고 기피되었으므로 경고만 했습니다(예 btw, gl에 투표하고 있습니다!)

@LikeLakers2 간단히 보면 그렇습니다.

@girng 글쎄, 그것이 제안된 기능에 정말로 의존하기를 바랍니다. 솔직히, 이것조차도 하나 를 갖는 것이 더 살 수 있지만 일반적인 경우를 조금 더 멋지게 만들 것입니다.

아, 그럼 이 아이디어가 지지를 얻습니다. 그 splat 연산자는 Ruby에서 너무 유용합니다.

고급 멀티플레이어 rpc 기능은 이미 이 작업을 수행합니다. 어떤 식 으로든 액세스 할 수있는 방법입니까?

간단한 사용자 정의 로깅 기능을 구현할 수 있기를 바랍니다.

우리는 이미 다음을 수행할 수 있습니다.

print("Score: ", score)

그러나 다음과 같은 작업도 수행할 수 있으면 좋을 것입니다.

_log("Score: ", score)

여기서 log 출력은 다음을 생성합니다.

[MyClass] Score: 500

간단한 사용자 정의 로깅 기능을 구현할 수 있기를 바랍니다.

우리는 이미 다음을 수행할 수 있습니다.

print("Score: ", score)

그러나 다음과 같은 작업도 수행할 수 있으면 좋을 것입니다.

_log("Score: ", score)

여기서 log 출력은 다음을 생성합니다.

[MyClass] Score: 500

이것에 하나를 더할 수 있습니까 ... 또한 인쇄가 불쾌하지만 다른 사람들이 좋아할 수 있으므로 Python (문자열 및 숫자 등)과 같이 정상적으로 인쇄되는 인쇄 기능을 만들고 싶습니다.

나는 이것이 gdscript에서 정말 멋진 기능이 될 것이라고 생각합니다. 배열 없이 여러 인수를 전달할 수 있는 기능은 사용자 지정 로그 함수와 같은 경우에 매우 유용합니다!

게임을 만드는 한 이 문제를 피할 수 있다고 주장할 수 있지만(그리고 당신이 절대적으로 옳을 것입니다), """노출"""하려는 Godot 자체의 도구 제작자에게는 놀라운 유익한 기능이 될 것입니다. 사용자에게 유연한 API를 제공합니다.

기술적으로 모든 것이 어떤 의미에서 노출되기 때문에 노출은 따옴표로 묶여 있습니다.

일부 기능은 이미 varargs 이지만 재정의할 방법이 없기 때문에 이 기능이 정말 필요하다고 생각합니다.

나는 gdscript의 varargs를 원합니다. 고려하다:

func rpc_game_info(node:Node, method:String, args:vararg):
    for id in players:
        node.rpc_id(id, method, args)

현재 내가 생각할 수 있는 유일한 방법은 rpc_game_info 가 호출되는 모든 곳에 두 줄을 복사하여 붙여넣고 메서드 인수를 쉼표로 구분된 목록으로 제공하는 것입니다.

최소한 배열을 풀거나/확대/확장하는 방법이 있습니까? 즉, 이와 같은 작업을 수행하는 방법이 있습니까?:

func foo(bar: String, args = []):
  baz(bar, ...args)

@rosshadden Object::callv("method", [..args]) 사용할 수 있습니다.

저는 2012년부터 웹사이트, 백엔드, 게임을 위한 C/C++/Js 코드를 많이 작성해 왔으며 varargs를 반드시 사용해야 했던 상황을 기억할 수 없습니다. 디버그 메시지를 기록하는 데는 좋은 기능이지만 그 외에는 필요하지 않습니다. 사실, 저는 Godot 게임을 만든지 1년이 넘었고 지금 gdscript가 어디에 있는지 매우 만족합니다. 언어에 종소리와 휘파람을 추가하는 데 시간을 보내는 대신 기존 기능의 효율성을 개선하는 데 투표하고 싶습니다. 안부 인사, - Alexandre Kharlamov

저는 2012년부터 웹사이트, 백엔드, 게임을 위한 C/C++/Js 코드를 많이 작성해 왔으며 varargs를 반드시 사용해야 했던 상황을 기억할 수 없습니다. 디버그 메시지를 기록하는 데는 좋은 기능이지만 그 외에는 필요하지 않습니다. 사실, 저는 Godot 게임을 만든지 1년이 넘었고 지금 gdscript가 어디에 있는지 매우 만족합니다. 언어에 종소리와 휘파람을 추가하는 데 시간을 보내는 대신 기존 기능의 효율성을 개선하는 데 투표하고 싶습니다. 안부 인사, - Alexandre Kharlamov

좋긴 한데, 자원봉사자가 자발적으로 이를 시행할 가능성이 있는 경우 귀하의 투표가 아무 의미가 없다는 점을 유감스럽게 생각합니다.

@mitchcurtis 논의된 문제와 관련이 없는 댓글은 삼가해 주십시오. 다른 사람을 경시하는 것은 토론에 긍정적으로 기여하지 않습니다.

많은 사람들이 "종소리와 휘파람"을 요구하는 기능을 호출하는 것이 다른 사람을 얕잡아 보지 않는 방법은 무엇입니까? 내 의견은 당면한 문제와 직접적인 관련이 있습니다. 이는 오픈 소스 프로젝트이며 많은 커밋은 작업할 항목을 선택하는 기여자들의 것입니다.

뒤집어 봅시다. Alexandre의 의견이 토론에 긍정적으로 기여합니까? 다른 사람들이 원하는 기능을 얕잡아 보는 것보다 자신이 관심 있는 특정 기능을 찾아 지원하는 것이 더 좋지 않았을까요?

기능을 구현하는 것은 "누가 원하는지"와 "누가 구현할 수 있는지"에 관한 것이 아닙니다. 기능이 실제로 필요하지 않은 경우 구현을 피해야 하므로 "필요하지 않다고 생각하는 사람(및 왜)"을 아는 것도 중요합니다. 코드 유지 관리를 더 어렵게 만들고 성능에 영향을 미치며 최적화 가능성 등을 줄일 수 있습니다(특히 스크립팅 언어에서).

예, @alexkh 의 피드백은 동의하지 않더라도 흥미로운 것입니다. 누군가는 내일 이 기능에 대한 완벽한 PR을 제공할 수 있습니다. 핵심 기여자는 여전히 기술 및 API 디자인 관점에서 이것이 추가할 가치가 있는지 생각하고 토론하는 데 상당한 시간을 할애해야 합니다.

GDScript의 범위를 작고 유지하기 쉽게 유지하는 것은 확실히 언어의 핵심 설계 원칙 중 하나입니다. 이 특정 기능이 좋은 추가 기능이 아니라는 말은 아니지만, 제안에 동의하지 않는 사람들의 의견을 경청하는 것을 의미하는 찬반 양론을 저울질해야 합니다.

기능을 구현하는 것은 "누가 원하는지"와 "누가 구현할 수 있는지"에 관한 것이 아닙니다. 기능이 실제로 필요하지 않은 경우 구현을 피해야 하므로 "필요하지 않다고 생각하는 사람(및 왜)"을 아는 것도 중요합니다. 코드 유지 관리를 더 어렵게 만들고 성능에 영향을 미치며 최적화 가능성 등을 줄일 수 있습니다(특히 스크립팅 언어에서).

예, @alexkh 의 피드백은 동의하지 않더라도 흥미로운 것입니다. 누군가는 내일 이 기능에 대한 완벽한 PR을 제공할 수 있습니다. 핵심 기여자는 여전히 기술 및 API 디자인 관점에서 이것이 추가할 가치가 있는지 생각하고 토론하는 데 상당한 시간을 할애해야 합니다.

GDScript의 범위를 작고 유지하기 쉽게 유지하는 것은 확실히 언어의 핵심 설계 원칙 중 하나입니다. 이 특정 기능이 좋은 추가 기능이 아니라는 말은 아니지만, 제안에 동의하지 않는 사람들의 의견을 경청하는 것을 의미하는 찬반 양론을 저울질해야 합니다.

공정한 포인트.

이 문제에 대한 득표수가 그 자체로 말해주는 것이라고 생각하지만, 앞으로는 그런 언급을 삼가도록 노력하겠습니다.

저는 2012년부터 웹사이트, 백엔드, 게임을 위한 C/C++/Js 코드를 많이 작성해 왔으며 varargs를 반드시 사용해야 했던 상황을 기억할 수 없습니다. 디버그 메시지를 기록하는 데는 좋은 기능이지만 그 외에는 필요하지 않습니다. 사실, 저는 Godot 게임을 만든지 1년이 넘었고 지금 gdscript가 어디에 있는지 매우 만족합니다. 언어에 종소리와 휘파람을 추가하는 데 시간을 보내는 대신 기존 기능의 효율성을 개선하는 데 투표하고 싶습니다. 안부 인사, - Alexandre Kharlamov

저는 다양한 게임, 프로그램, 그리고 직장에서 15년 이상 프로그래밍을 하고 있습니다. 그러나 Godot에서 한 달 동안만 제가 말할 수 있는 것은, 특정 기능 요청으로 이미 열려 있는 여러 기능이 그리웠다는 것입니다. 이 기능. 다양한 수의 인수를 수락하고 보낼 수 있는 것은 내가 꽤 자주 필요로 하는 것이며 문제를 해결해야 하는 경우 코드의 품질을 크게 떨어뜨리고 있습니다.

한 가지 예: => 상속

class A
_init(arg0, arg1, arg2)

class B extends A
_init(arg0, arg1, arg2, arg4).(arg0, arg1, arg2)

이제 클래스 A의 인수 목록을 변경해야 한다고 상상해 보십시오. 이 클래스를 상속하는 모든 클래스를 찾아야 하므로 위험합니다. 사실에도 불구하고 명명 된 인수가 없으므로 인수 목록을 혼동하는 것 자체의 문제입니다.

또 다른 예는 콜백입니다. 이것은 코드 없이 진행되는 것 같습니다 ...

그래서 제 요점은: Godot는 아직 필요한 모든 것을 제공하지는 않습니다. 단지 중요한 모든 것을 수행합니다(물론 훨씬 더 :) ...). 그러나 기능 추가를 중단하는 것이 가장 좋은 경우는 아직 아닙니다. 그러나 무엇을 추가할지 신중하게 결정하는 것이 좋습니다.

편집: 방금 또 다른 좋은 예가 godots 자신의 Object.call() 메서드임을 깨달았습니다 ;)

DamKoVosh, 가장 큰 게임이 몇 줄의 코드인지 알려주세요. 게임을 만들 때마다 얼마나 적은 코딩이 필요한지 실망합니다. 작업의 대부분은 항상 콘텐츠, 테스트, 게임 플레이 균형 조정입니다. 당신은 다시 쓰는 것이 위험하다고 말합니다. 다른 것이 아니라면 코드를 다시 작성하면 미래 지향적인 인터페이스와 데이터 구조를 더 잘 작성할 수 있습니다!

이 스레드의 첫 번째 메시지에서 언급했듯이 전체 토론은 가변 함수를 구현하는 대신 배열을 사용하여 이미 쉽게 구현할 수 있는 구문 설탕에 대한 것입니다.

@alexkh

이 스레드의 첫 번째 메시지에서 언급했듯이 전체 토론은 가변 함수를 구현하는 대신 배열을 사용하여 이미 쉽게 구현할 수 있는 구문 설탕에 대한 것입니다.

Geequlim 이 rpc , emit_signal 와 같은 varargs를 사용하는 함수를 재정의하는 기능을 실제로 깨뜨립니다 rpc 필요에 따라 rpc 을 변경하려고 했습니다.

예, 구문 설탕입니다. 그러나 구문 설탕이라는 것이 그것이 좋거나 나쁘다는 것을 의미하지는 않습니다. if , else 와 같은 제어 흐름과 심지어 함수도 GOTO 위에 있는 설탕일 뿐입니다. 그게 당신이 그것들을 원하지 않는다는 것을 의미하지는 않습니다.

때로는 약간의 합성 설탕을 추가하면 코드를 더 읽기 쉽게 만들고 복잡성을 추가할 가치가 있습니다.

그러나 실제로는 rpc, emit_signal과 같은 varargs를 사용하는 함수를 재정의하는 기능을 중단합니다.

이러한 함수가 배열이 아닌 varargs를 사용한다는 점이 궁금합니다. ;-) Godot API 자체가 다양한 장소에서 varargs를 어떻게 사용하는지 주목하세요? 거기에는 아마 이유가 있을 것입니다.

또한 얼마나 많은 언어가 가변 함수를 구현하는지 궁금합니다. "배열을 사용하여 쉽게 구현"할 수 있더라도 유용합니까?

나는 그것을 사용할 때마다 GDScript에서 그것들을 그리워하고 있으며, 이것이 내가 C#을 선호하는 이유 중 하나입니다. 또는 C++. 또는 자바. 또는 파이썬. 또는 이동.

솔직히 말해서, GDScript는 내가 작업한 유일한 언어 중 그런 기능이 없는 언어라고 생각합니다. 게다가 루아? 아, 확인해보니 거기에도 있는 것 같습니다. 해당 언어가 가지고 있는 모든 것을 GDScript에 추가하는 것을 목표로 해야 한다는 것은 아니지만, 모든 언어에 공통된 기능 이 있다면 그만한 가치가 있을

GDScript 백엔드에 얼마나 많은 복잡성이 추가될지 판단할 수 없으므로 복잡성 트레이드오프에 대해 많이 말할 수 없지만 "단순한 구문 설탕"이기 때문에 그것들을 쓰는 것은 잘못된 것입니다. 많은 것들.

다시, Godot에서 얼마나 많은 것들이 그것들을 사용하는지 주목하십시오.

예, 구문 설탕입니다. 그러나 구문 설탕이라는 것이 그것이 좋거나 나쁘다는 것을 의미하지는 않습니다. if , else 와 같은 제어 흐름과 심지어 함수도 GOTO 위에 있는 설탕일 뿐입니다. 그게 당신이 그것들을 원하지 않는다는 것을 의미하지는 않습니다.

무조건 점프이기 때문에 GOTO를 대체하지 않습니다. 당신도 프로그래머입니까?

그러나 실제로는 rpc, emit_signal과 같은 varargs를 사용하는 함수를 재정의하는 기능을 중단합니다.

1년에 한 번 누군가가 rpc 기능을 재정의하고 싶어할 것입니다. 수천 명의 다른 사람들이 매일 Godot 4가 출시되는 것을 보고 싶어합니다.

또한 얼마나 많은 언어가 가변 함수를 구현하는지 궁금합니다. "배열을 사용하여 쉽게 구현"할 수 있더라도 유용합니까?

나는 그것을 사용할 때마다 GDScript에서 그것들을 그리워하고 있으며, 이것이 내가 C#을 선호하는 이유 중 하나입니다. 또는 C++. 또는 자바. 또는 파이썬. 또는 이동.

C++에는 GDscript처럼 다른 유형의 값을 저장할 수 있는 표준 배열 유형이 없습니다. C++는 가변 함수를 지원하지만 형식이 안전하지 않기 때문에 사용하지 않는 것이 좋습니다. 이것은 C 레거시이며 C 자체에서는 구문상의 설탕이었습니다. 특히 디버깅을 위해 printf가 많이 사용되었기 때문입니다. 임시 코드를 빠르게 입력하여 일부 데이터를 출력하려는 ​​경우에 그렇습니다. 그것은 항상 사용되었기 때문에 완전히 정당화되었습니다 - 실시간 절약기! 그러나 C 또는 C++로 고유한 가변 함수를 작성한 적이 있습니까?

다시, Godot에서 얼마나 많은 것들이 그것들을 사용하는지 주목하십시오.

디버그 출력을 위해 - 꼭! 그러나 print()가 가변적이지 않으면 print("Hello ", "World) 대신 print(["Hello ", "World"])를 입력해야 합니다 - 큰 차이는 없습니다...

무조건 점프이기 때문에 GOTO를 대체하지 않는다.

글쎄, 맞아. 물론 조건부 점프에 대해 이야기하고 있었습니다. 어느 ... 추측 할 수 있습니다. 그래도 요점은 다음과 같습니다. 일부 내용을 보다 명확하게 전달할 수 있도록 상위 수준 기능을 구축했습니다.

C++에는 GDscript처럼 다른 유형의 값을 저장할 수 있는 표준 배열 유형이 없습니다.

좋아, Python, Lua 또는 Go(또는 다른 언어의 호스트)에 대해 논쟁을 벌이십시오. 그런 다음 그것들이 있고 여전히 가변적 기능을 가지고 있습니다.

그러나 print()가 가변적이지 않은 경우 print("Hello ", "World) 대신 print(["Hello ", "World"])를 입력해야 합니다. 큰 차이는 없습니다.

물론, 그 간단한 테스트 케이스에서. 더 복잡한 데이터에서는 더 보기 흉해집니다. 특히 여러 소스에서 데이터를 가져오기 시작하고 이제 수동으로 이를 배열에 먼저 채워야 하는 경우 더욱 그렇습니다. 나는 그것이 큰 손실이 아니라는 데 동의합니다. 여전히 variadic 함수는 경우에 따라 더 깨끗한 코드를 만듭니다.

하지만...

그러나 C 또는 C++로 고유한 가변 함수를 작성한 적이 있습니까?

당신도 프로그래머입니까?

위와 같이 선의의 논쟁을 하는 것 같지는 않습니다. 어떤 경우에는 더 이상 당신과 이야기하는 데 정말로 관심이 없습니다. 그래서... 아니요, 저는 좋은 마스코트를 만들기 위해 엔진 기여자로 나열될 뿐입니다. 계속 진행해 주세요.

무조건 점프이기 때문에 GOTO를 대체하지 않습니다. 당신도 프로그래머입니까?

대부분의 조건문, 특히 루프는 전문화된 점프 문일 뿐이며 대부분 goto 문과 동일합니다. 실용적인 의미에서 가장 기본적인 시퀀스 제어 문은 그 확장입니다. 이것은 당신 자신을 지지하는 어리석은 주장이며(실제로 논쟁을 하지 않기 때문에 그것은 쓸모없는 의미론을 주장할 뿐입니다) 두 번째 부분은 무례합니다.

C++에는 GDscript처럼 다른 유형의 값을 저장할 수 있는 표준 배열 유형이 없습니다. C++는 가변 함수를 지원하지만 형식이 안전하지 않기 때문에 사용하지 않는 것이 좋습니다. 이것은 C 레거시이며 C 자체에서는 구문상의 설탕이었습니다. 특히 디버깅을 위해 printf가 많이 사용되었기 때문입니다. 임시 코드를 빠르게 입력하여 일부 데이터를 출력하려는 ​​경우에 그렇습니다. 그것은 항상 사용되었기 때문에 완전히 정당화되었습니다 - 실시간 절약기! 그러나 C 또는 C++로 고유한 가변 함수를 작성한 적이 있습니까?

C++에는 varargs(또는 일반적으로 유형이 지정되지 않은 배열)에 대한 표준 배열 유형이 없지만 현재 약 10년 동안 이를 처리하는 방식이 먼저 존재합니다. 그리고 오히려 해키) 두 번째로 varadic 템플릿을 사용하면 입력 문제를 완전히 건너뛸 수 있습니다. Varadic 템플릿을 사용하여 C++에서 varargs를 처리하는 방법이 있습니다. C++의 varargs를 여전히 믿는 사람들은 아마도 요즘 잘못된 지점에서 시작하고 있을 것입니다.

나는 개인적으로 토론에 별로 신경 쓰지 않는다(개인적으로 백엔드에 앉아 있는 대신 GDScript에서 배열 기반 가변 인수 유형을 갖는 것이 더 깨끗하고 조직적이라는 점을 제외하고는 언어 기능이 구현되어야 한다고 생각합니다. 언어, 실행뿐만 아니라 저입니다.) 그러나 이러한 의견은 수정되어야 하며, 이 경우에는 다소 무례하게 행동하고 있다는 점을 제외하고, 이렇게 객관적으로 다루어야 할 반대에 대해 부정적으로 반응한다.

무조건 점프이기 때문에 GOTO를 대체하지 않습니다. 당신도 프로그래머입니까?

대부분의 조건문, 특히 루프는 전문화된 점프 문일 뿐이며 대부분 goto 문과 동일합니다. 실용적인 의미에서 가장 기본적인 시퀀스 제어 문은 그 확장입니다. 이것은 당신 자신을 지지하는 어리석은 주장이며(실제로 논쟁을 하지 않기 때문에 그것은 쓸모없는 의미론을 주장할 뿐입니다) 두 번째 부분은 무례합니다.

K, 나는 내 시간을 낭비하는 사람들에게 무례합니다. 그의 요점은: if 대신에 GOTO를 사용하지 않는 이유입니다. 그리고 저는 GOTO가 if를 대체하지 않는다고 말했습니다. GOTO는 조건문이 아니며 조건문을 대체하려면 대체할 내용을 정확히 입력하면 됩니다. 이미 예가 있습니까?

C++에는 GDscript처럼 다른 유형의 값을 저장할 수 있는 표준 배열 유형이 없습니다. C++는 가변 함수를 지원하지만 형식이 안전하지 않기 때문에 사용하지 않는 것이 좋습니다. 이것은 C 레거시이며 C 자체에서는 구문상의 설탕이었습니다. 특히 디버깅을 위해 printf가 많이 사용되었기 때문입니다. 임시 코드를 빠르게 입력하여 일부 데이터를 출력하려는 ​​경우에 그렇습니다. 그것은 항상 사용되었기 때문에 완전히 정당화되었습니다 - 실시간 절약기! 그러나 C 또는 C++로 고유한 가변 함수를 작성한 적이 있습니까?

C++에는 varargs(또는 일반적으로 유형이 지정되지 않은 배열)에 대한 표준 배열 유형이 없지만 현재 약 10년 동안 이를 처리하는 방식이 먼저 존재합니다. 그리고 오히려 해키) 두 번째로 varadic 템플릿을 사용하면 입력 문제를 완전히 건너뛸 수 있습니다. Varadic 템플릿을 사용하여 C++에서 varargs를 처리하는 방법이 있습니다. C++의 varargs를 여전히 믿는 사람들은 아마도 요즘 잘못된 지점에서 시작하고 있을 것입니다.

나는 개인적으로 토론에 별로 신경 쓰지 않는다(개인적으로 백엔드에 앉아 있는 대신 GDScript에서 배열 기반 가변 인수 유형을 갖는 것이 더 깨끗하고 조직적이라는 점을 제외하고는 언어 기능이 구현되어야 한다고 생각합니다. 언어, 실행뿐만 아니라 저입니다.) 그러나 이러한 의견은 수정되어야 하며, 이 경우에는 다소 무례하게 행동하고 있다는 점을 제외하고, 이렇게 객관적으로 다루어야 할 반대에 대해 부정적으로 반응한다.

K, 하지만 그게 정확히 제 요점입니다. GDscript에는 다른 유형을 보유할 수 있는 반복할 수 있는 표준 유형이 있으므로 C++에서 작동하는 가변 함수를 얻는 데 필요한 모든 해커를 엉망으로 만들 필요가 없습니다. , 아마도 C++에서는 가변 템플릿이 정당화될 수 있습니다.

K, 나는 내 시간을 낭비하는 사람들에게 무례합니다.

그러면 30일 동안 @godotengine 리포지토리에서 상호 작용할 수 없도록 차단되어 다른 프로젝트에 시간을 낭비할 수 있습니다.

우리는 행동 강령을 가지고 있으며 누구에게도 무례한 행동을

Godot 엔진에 대한 기능 및 개선 제안은 현재 전용 Godot 개선 제안(GIP) ( godotengine/godot-proposals ) 이슈 트래커에서 논의되고 검토되고 있습니다. GIP 추적기에는 제안서에 모든 관련 정보가 포함되어 생산적인 토론을 시작하고 커뮤니티가 엔진 제안서의 유효성을 평가하는 데 도움이 되도록 설계된 세부 문제 템플릿이 있습니다.

기본( godotengine/godot ) 추적기는 이제 전적으로 버그 보고서 및 끌어오기 요청 전용이므로 기여자가 버그 수정 작업에 더 집중할 수 있습니다. 따라서 이제 주요 이슈 트래커에서 이전 기능 제안을 모두 종료합니다.

이 기능 제안에 관심이 있으시면 주어진 문제 템플릿 에 따라 GIP 트래커에서 새 제안을 여십시오 (이미 존재하지 않는지 확인한 후). 관련 토론이 포함된 경우 이 닫힌 문제를 참조해야 합니다(새 제안에서 요약하는 것이 좋습니다). 미리 감사드립니다!