Godot: GDScript: функции с переменным числом аргументов (переменное количество аргументов / переменных)

Я правильно понимаю, мы говорим о чем-то вроде оператора splat в Ruby ?

в прошлый раз, когда я предложил что-то для gdscript, он довольно быстро отключился и избегался reduz, так что просто предупреждение (я голосую да, кстати, gl!)

@ LikeLakers2 Если коротко, то да.

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

Ну, тогда эта идея получила мою поддержку. Этот оператор splat слишком полезен в Ruby.

Многопользовательская функция высокого уровня rpc уже делает это. Это каким-то образом доступно?

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

Мы уже можем сделать следующее:

print("Score: ", score)

но было бы неплохо иметь возможность делать и следующее:

_log("Score: ", score)

где вывод журнала даст:

[MyClass] Score: 500

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

Мы уже можем сделать следующее:

print("Score: ", score)

но было бы неплохо иметь возможность делать и следующее:

_log("Score: ", score)

где вывод журнала даст:

[MyClass] Score: 500

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

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

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

expose заключен в кавычки, потому что технически в определенном смысле раскрыто все.

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

Я бы хотел varargs в gdscript. Рассмотреть возможность:

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])

Я пишу много кода C / C ++ / Js для веб-сайтов, бэкэндов, игр с 2012 года, и я не могу вспомнить ситуацию, когда мне абсолютно необходимо было использовать varargs. Это хорошая функция для регистрации отладочных сообщений, но кроме этого, я не вижу в ней необходимости. Фактически, я делаю игры Godot уже больше года, и я вполне доволен тем, где сейчас gdscript: он делает все, что мне нужно, и даже больше. Вместо того, чтобы тратить время на добавление лишних наворотов в язык, я бы скорее проголосовал за повышение эффективности существующей функциональности. С уважением, - Александр Харламов

Я пишу много кода C / C ++ / Js для веб-сайтов, бэкэндов, игр с 2012 года, и я не могу вспомнить ситуацию, когда мне абсолютно необходимо было использовать varargs. Это хорошая функция для регистрации отладочных сообщений, но кроме этого, я не вижу в ней необходимости. Фактически, я делаю игры Godot уже больше года, и я вполне доволен тем, где сейчас gdscript: он делает все, что мне нужно, и даже больше. Вместо того, чтобы тратить время на добавление лишних наворотов в язык, я бы скорее проголосовал за повышение эффективности существующей функциональности. С уважением, - Александр Харламов

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

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

Как назвать функцию, о которой многие просят «навороты», не преуменьшает значение других? Мой комментарий напрямую связан с рассматриваемой проблемой - это проект с открытым исходным кодом, и многие коммиты исходят от участников, которые выбирают, над чем они хотят работать.

Давайте перевернемся: положительно ли повлиял на обсуждение комментарий Александра? Разве не было бы лучше для него найти конкретную функцию, которая его интересовала, и продемонстрировать ее поддержку вместо того, чтобы преуменьшать значение функций, которые нужны другим?

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

Так что да, отзыв @alexkh интересен, даже если вы с ним не согласны. Кто-то может прийти с идеальным PR для этой функции завтра, основным участникам все равно придется потратить некоторое время на размышления и обсуждения, стоит ли добавлять это с технической точки зрения и с точки зрения дизайна API.

Сохранение объема GDScript небольшого размера и простоты обслуживания, безусловно, является одним из основных принципов проектирования языка. Я не говорю, что эта особенность не будет хорошим дополнением, но мы должны взвесить все «за» и «против», что подразумевает выслушивание тех, кто не согласен с предложением.

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

Так что да, отзыв @alexkh интересен, даже если вы с ним не согласны. Кто-то может прийти с идеальным PR для этой функции завтра, основным участникам все равно придется потратить некоторое время на размышления и обсуждения, стоит ли добавлять это с технической точки зрения и с точки зрения дизайна API.

Сохранение объема GDScript небольшого размера и простоты обслуживания, безусловно, является одним из основных принципов проектирования языка. Я не говорю, что эта особенность не будет хорошим дополнением, но мы должны взвесить все «за» и «против», что подразумевает выслушивание тех, кто не согласен с предложением.

Справедливые баллы.

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

Я пишу много кода C / C ++ / Js для веб-сайтов, бэкэндов, игр с 2012 года, и я не могу вспомнить ситуацию, когда мне абсолютно необходимо было использовать varargs. Это хорошая функция для регистрации отладочных сообщений, но кроме этого, я не вижу в ней необходимости. Фактически, я делаю игры Godot уже больше года, и я вполне доволен тем, где сейчас gdscript: он делает все, что мне нужно, и даже больше. Вместо того, чтобы тратить время на добавление лишних наворотов в язык, я бы скорее проголосовал за повышение эффективности существующей функциональности. С уважением, - Александр Харламов

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

Один пример: => наследование

class A
_init(arg0, arg1, arg2)

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

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

Другой пример - обратные вызовы, я предполагаю, что это происходит без кода ...

Итак, я хочу сказать: godot еще не все, что вам нужно, он просто делает все, что важно (ну и, конечно, еще кое-что :) ...). Но, тем не менее, это еще не тот момент, когда прекращение добавления функций было бы лучшим случаем. Однако быть осторожным с тем, что добавить, - хорошее решение.

Изменить: только что понял, что еще один хороший пример - это собственный метод Object.call () Godots;)

ДамКоВош, скажите, пожалуйста, сколько строк кода было вашей самой большой игрой? Каждый раз, когда я делаю игру, я разочаровываюсь тем, как мало для нее требуется кодирования. Основная часть работы - это всегда контент, тестирование, балансировка игрового процесса. Вы говорите, что переписывание опасно. По крайней мере, переписывание кода поможет вам лучше писать ориентированные на будущее интерфейсы и структуры данных!

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

@alexkh

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

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

Да, это синтаксический сахар. Однако синтаксический сахар не означает, что они хороши или плохи. Поток управления, такой как if , else и даже функции, тоже являются сахаром поверх GOTO если хотите. Это не значит, что они вам не нужны.

Иногда добавление небольшого количества синтаксического сахара делает код более читаемым и стоит дополнительной сложности.

но на самом деле нарушает возможность переопределения функций, использующих varargs, таких как rpc, emit_signal

Любопытно, что эти функции используют varargs, а не массивы. ;-) Обратите внимание, как сам Godot API использует varargs в разных местах? Вероятно, для этого есть причина.

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

Мне их очень не хватает в GDScript всякий раз, когда я его использую, и это одна из причин, по которой я предпочитаю C #. Или C ++. Или Java. Или Python. Или пойти.

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

Я не могу судить, сколько сложности это добавит бэкэнду GDScript, и поэтому не могу много сказать о компромиссе сложности, но списывать их, потому что они «просто синтаксический сахар», неправильно, потому что это можно сказать о много вещей.

Опять же, обратите внимание, сколько вещей в Godot их используют.

Да, это синтаксический сахар. Однако синтаксический сахар не означает, что они хороши или плохи. Поток управления, такой как if , else и даже функции, тоже являются сахаром поверх GOTO если хотите. Это не значит, что они вам не нужны.

GOTO не заменяет if, потому что это безусловный переход. Вы хоть программист?

но на самом деле нарушает возможность переопределения функций, использующих varargs, таких как rpc, emit_signal

раз в год кто-нибудь где-нибудь захочет переопределить функцию rpc. А тысячи других каждый день желают увидеть выпуск Godot 4.

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

Мне их очень не хватает в GDScript всякий раз, когда я его использую, и это одна из причин, по которой я предпочитаю C #. Или C ++. Или Java. Или Python. Или пойти.

В C ++ нет стандартного типа массива, который может хранить значения разных типов, как это делает GDscript. Несмотря на то, что C ++ поддерживает функции с переменным числом аргументов, их использование не рекомендуется, поскольку это небезопасный тип. Это наследие C, а в самом C это был синтаксический сахар, потому что printf часто использовался, особенно для отладки, когда вы хотите быстро ввести временный код для вывода некоторых данных. Это было полностью оправдано, потому что им пользовались постоянно - реальная экономия времени! Но вы когда-нибудь писали свою собственную вариационную функцию на C или C ++?

Опять же, обратите внимание, сколько вещей в Godot их используют.

Для вывода отладки - во что бы то ни стало! Но если бы print () не был вариативным, вместо print ("Hello", "World) вам нужно было бы набрать print ([" Hello "," World "]) - совсем не большая разница ...

GOTO не заменяет if, потому что это безусловный переход

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

В C ++ нет стандартного типа массива, который может хранить значения разных типов, как это делает GDscript.

Хорошо, возразите против Python, Lua или Go (или любого множества других языков), у которых они есть, но все еще имеют вариативные функции.

Но если бы print () не был вариативным, вместо print ("Hello", "World) вам нужно было бы ввести print ([" Hello "," World "]) - совсем не большая разница.

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

Но...

Но вы когда-нибудь писали свою собственную вариационную функцию на C или C ++?

Вы хоть программист?

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

GOTO не заменяет if, потому что это безусловный переход. Вы хоть программист?

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

В C ++ нет стандартного типа массива, который может хранить значения разных типов, как это делает GDscript. Несмотря на то, что C ++ поддерживает функции с переменным числом аргументов, их использование не рекомендуется, поскольку это небезопасный тип. Это наследие C, а в самом C это был синтаксический сахар, потому что printf часто использовался, особенно для отладки, когда вы хотите быстро ввести временный код для вывода некоторых данных. Это было полностью оправдано, потому что им пользовались постоянно - реальная экономия времени! Но вы когда-нибудь писали свою собственную вариационную функцию на C или C ++?

В то время как C ++ не имеет стандартного типа массива для varargs (или нетипизированных массивов в целом), сначала существуют способы справиться с этим уже около десяти лет (технически вы могли сделать это даже до C ++ 11, но это было очень тяжело для макросов. и довольно хакерский), а во-вторых, с вариативными шаблонами вы можете полностью избавиться от проблем с набором текста. Есть способы работать с varargs в C ++ с использованием varadic-шаблонов. Те, кто все еще верит в varargs в C ++, вероятно, сейчас начинают не с той точки.

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

GOTO не заменяет if, потому что это безусловный переход. Вы хоть программист?

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

К. Я неуважительно отношусь к людям, которые зря тратят мое время. Его точка зрения была такова: почему бы не использовать GOTO вместо if, и я сказал, что GOTO не заменяет if. GOTO не является условным оператором, и если вы хотите заменить условный оператор, просто введите то, чем именно вы хотите его заменить. Уже есть примеры?

В C ++ нет стандартного типа массива, который может хранить значения разных типов, как это делает GDscript. Несмотря на то, что C ++ поддерживает функции с переменным числом аргументов, их использование не рекомендуется, поскольку это небезопасный тип. Это наследие C, а в самом C это был синтаксический сахар, потому что printf часто использовался, особенно для отладки, когда вы хотите быстро ввести временный код для вывода некоторых данных. Это было полностью оправдано, потому что им пользовались постоянно - реальная экономия времени! Но вы когда-нибудь писали свою собственную вариационную функцию на C или C ++?

В то время как C ++ не имеет стандартного типа массива для varargs (или нетипизированных массивов в целом), сначала существуют способы справиться с этим уже около десяти лет (технически вы могли сделать это даже до C ++ 11, но это было очень тяжело для макросов. и довольно хакерский), а во-вторых, с вариативными шаблонами вы можете полностью избавиться от проблем с набором текста. Есть способы работать с varargs в C ++ с использованием varadic-шаблонов. Те, кто все еще верит в varargs в C ++, вероятно, сейчас начинают не с той точки.

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

K, но это именно моя точка зрения: GDscript имеет стандартный тип, который вы можете повторять и который может содержать в себе разные типы, поэтому вам не нужно возиться со всеми хакерскими приемами, необходимыми для работы вариативных функций на C ++, и вот почему Возможно, в C ++ оправданы вариативные шаблоны.

К. Я неуважительно отношусь к людям, которые зря тратят мое время.

Тогда я позволю вам тратить ваше время на другие проекты, поскольку теперь вы заблокированы от взаимодействия с репозиториями @godotengine в течение 30 дней.

У нас есть Кодекс поведения , который определенно не позволяет проявлять неуважение к кому-либо .

Предложения по функциям и улучшениям для Godot Engine сейчас обсуждаются и рассматриваются в специальном Godot Improvement Proposals (GIP) ( godotengine / godot-предложения ). В трекере GIP есть подробный шаблон проблемы, разработанный таким образом, чтобы предложения включали всю необходимую информацию, чтобы начать продуктивное обсуждение и помочь сообществу оценить обоснованность предложения для движка.

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

Если вас интересует это предложение по функциям, откройте новое предложение в трекере GIP, следуя заданному шаблону проблемы (после проверки того, что его еще нет). Обязательно укажите этот закрытый вопрос, если он включает какое-либо соответствующее обсуждение (которое вам также рекомендуется резюмировать в новом предложении). Заранее спасибо!