Чистые функции хорошо взаимодействуют с пайпами, но всё же я акцентировал внимание на отсутствии шума от промежуточных переменных и т.п. Это разные плюшки, хоть они зачастую и идут пакетом. Существуют DSL, адаптированные под пайпы, где каждая строка обладает неслабым сайд-эффектом. В Godot без этого не обойтись из-за устройства API некоторых сервисов.
Да, функции тоже можно. Так работает кодоген по Swagger и т.п. Однако по моему опыту в F# на основе внешнего источника данных чаще генерируются структуры данных, а не функции. Для последних характерно использование рефлексии по существующим библиотекам, то есть источник данных скорее внутренний.
Лет 6-7 назад в C# уже был рослин, которые позволял ворочить AST непосредственно в VS. Я практически не пробовал вытаскивать его наружу, но не думаю, что это вызовит серьёзные сложности. Кроме того в C# есть сорсгены, но они обычно подразумевают более общие задачи без серьёзной кастомизации.
partial в неумелых руках может превратить проект в кашу, но в случае с Godot разрабы накидали своих фишек.
В Godot всё описывается через ноды, которые могут вкладываться друг в друга без ограничений, за счёт чего получаются очень раскидистые деревья. Это напоминает UI-фреймворки, но в качестве ноды может быть объект, который отвечает только за логику и вообще никак не взаимодействует с UI. У этих нод есть свойства и события, но они полностью не закрывают всех фич, часть из которых доступна только через переопределение методов. Проблема в том, что просто переопределить метод недостаточно, ещё важно сделать это в нужном месте проекта.
Для того, чтобы Godot узнал о override в типе, этот тип должен лежать в C#-проекте и быть partial. Если я просто закину анонимную ноду в глубине сцены:
{ new Node() with
override this._Process delta =
if Input.IsKeyPressed Key.Shift then
GD.print "Shift pressed!!!"
}
То Godot никогда не вызовет метод _Process, потому что будет считать, что он не был изменён. Я пока не понял, почему они сделали именно так, но проблему приходится решать через создание прослойки вида:
public partial class InCSharp : InFSharp
{
public override void _Process(double delta) => base._Process(delta);
}
На каждый тип вида:
type InFSharp () =
override this._Process delta =
()
Получается, что я:
Не могу избавиться от C#-проекта.
Вынужден дублировать все ключевые типы с переопределениями.
Вынужден создавать их через фабрики, так как вместо InFSharp() мне надо неявно вызвать InCSharp().
Кроме того есть проблемы с экспортируемыми свойстваи и сигналами, которые также надо протаскивать через C#.
Я постепенно закатываю весь этот шум в асфальт и уже явно вышел в плюс, но мне не понятно, зачем этот комплекс проблем вообще был создан. В 3 версии Godot такой проблемы не было.
В оригинале данное словосочетание также закавычено. Я уверен, что оно было применено в контексте ложного тезиса "dotnet = C#". Например указанный раздел документации находится в главе "Сборка и управление зависимостями функции на С#"..
У меня не сформировался условно стартовый пакет статей для ввода новичков в Hopac. Ибо это происходит всё реже, и мне с практической точки зрения проще показать несколько конкретных примеров из существующих репозиториев, чем отправлять человека за выработкой решения в интернет.
Документация из начала статьи хороша, но её желательно каким-то образом употребить сразу в больших количествах. В этом случае она приближается к идеалу.
Если нужен поэтапный ввод, то можно попробовать цикл на Demystify (https://www.demystifyfp.com/tags/hopac/). Сам я учился иначе и знаком с ним поверхностно, но знакомые находили его самостоятельно и пробовали что-то писать на основе него. Потом приходилось латать некоторые прорехи, но в целом внятное представление о Hopac цикл даёт.
Ещё есть попсовые (в хорошем смысле) доклады от Худайгулова (https://youtu.be/G1L5YdUm_gU и https://www.youtube.com/watch?v=cSOnmVqOwBs). Из первого я когда-то узнал о Hopac. Было это во времена синхронные записи доклада, и тогда меня всё это дело очень впечатлило. Однако полноценно писать на Hopac я начал лишь спустя полтора года. В первую очередь под давлением возрастающей сложности и объёмов бизнес-логики, а не пиара.
Чистые функции хорошо взаимодействуют с пайпами, но всё же я акцентировал внимание на отсутствии шума от промежуточных переменных и т.п. Это разные плюшки, хоть они зачастую и идут пакетом. Существуют DSL, адаптированные под пайпы, где каждая строка обладает неслабым сайд-эффектом. В Godot без этого не обойтись из-за устройства API некоторых сервисов.
Да, функции тоже можно. Так работает кодоген по Swagger и т.п. Однако по моему опыту в F# на основе внешнего источника данных чаще генерируются структуры данных, а не функции. Для последних характерно использование рефлексии по существующим библиотекам, то есть источник данных скорее внутренний.
Лет 6-7 назад в C# уже был рослин, которые позволял ворочить AST непосредственно в VS. Я практически не пробовал вытаскивать его наружу, но не думаю, что это вызовит серьёзные сложности. Кроме того в C# есть сорсгены, но они обычно подразумевают более общие задачи без серьёзной кастомизации.
partialв неумелых руках может превратить проект в кашу, но в случае с Godot разрабы накидали своих фишек.В Godot всё описывается через ноды, которые могут вкладываться друг в друга без ограничений, за счёт чего получаются очень раскидистые деревья. Это напоминает UI-фреймворки, но в качестве ноды может быть объект, который отвечает только за логику и вообще никак не взаимодействует с UI. У этих нод есть свойства и события, но они полностью не закрывают всех фич, часть из которых доступна только через переопределение методов. Проблема в том, что просто переопределить метод недостаточно, ещё важно сделать это в нужном месте проекта.
Для того, чтобы Godot узнал о
overrideв типе, этот тип должен лежать в C#-проекте и бытьpartial. Если я просто закину анонимную ноду в глубине сцены:То Godot никогда не вызовет метод
_Process, потому что будет считать, что он не был изменён. Я пока не понял, почему они сделали именно так, но проблему приходится решать через создание прослойки вида:На каждый тип вида:
Получается, что я:
Не могу избавиться от C#-проекта.
Вынужден дублировать все ключевые типы с переопределениями.
Вынужден создавать их через фабрики, так как вместо
InFSharp()мне надо неявно вызватьInCSharp().Кроме того есть проблемы с экспортируемыми свойстваи и сигналами, которые также надо протаскивать через C#.
Я постепенно закатываю весь этот шум в асфальт и уже явно вышел в плюс, но мне не понятно, зачем этот комплекс проблем вообще был создан. В 3 версии Godot такой проблемы не было.
В оригинале данное словосочетание также закавычено. Я уверен, что оно было применено в контексте ложного тезиса "dotnet = C#". Например указанный раздел документации находится в главе "Сборка и управление зависимостями функции на С#"..
У меня не сформировался условно стартовый пакет статей для ввода новичков в
Hopac. Ибо это происходит всё реже, и мне с практической точки зрения проще показать несколько конкретных примеров из существующих репозиториев, чем отправлять человека за выработкой решения в интернет.Документация из начала статьи хороша, но её желательно каким-то образом употребить сразу в больших количествах. В этом случае она приближается к идеалу.
Если нужен поэтапный ввод, то можно попробовать цикл на Demystify (https://www.demystifyfp.com/tags/hopac/). Сам я учился иначе и знаком с ним поверхностно, но знакомые находили его самостоятельно и пробовали что-то писать на основе него. Потом приходилось латать некоторые прорехи, но в целом внятное представление о
Hopacцикл даёт.Ещё есть попсовые (в хорошем смысле) доклады от Худайгулова (https://youtu.be/G1L5YdUm_gU и https://www.youtube.com/watch?v=cSOnmVqOwBs). Из первого я когда-то узнал о
Hopac. Было это во времена синхронные записи доклада, и тогда меня всё это дело очень впечатлило. Однако полноценно писать наHopacя начал лишь спустя полтора года. В первую очередь под давлением возрастающей сложности и объёмов бизнес-логики, а не пиара.