Дженерики имеются ввиду, что в php могу сделать переменные с именами из строк, наподобие ${$arr[0]},которые генерятся . В го так нельзя
дело не в дженериках, дело в интерпретации.
но если очень хочется - можно билдить и запускать go код при обнаружении изменени. старый экземпляр останавливать, понятное дело.
как с этим кодом общаться - решайте сами
Daniel
🄽🄸🄺🄸🅃🄰
Если поменялись сущности, то и код их обработки должен поменяться. Как это сделать с перекомпиляцией и рестартом — так же, как в вебе делают миграции БД и перевыкат. Как это сделать без перекомпиляции — хранить код снаружи, т.е. обработку сделать на скриптовом движке, т.е. встроить в приложение lua, js, python, etc. Поменялись сущности - приложение поняло, обновило скрипты, работает с новой версией сущностей и кода.
Касательно перекомпиляции -да, я держу это в микросервисах и могу рестартить докер контейнеры. Сложно но можно. Но придется написать генератор этих структур и их обработки с формулами.
Касательно использования Lua, скажите куда копать. Я слышал но не пользовался
🄽🄸🄺🄸🅃🄰
В php нет дженериков
https://m.habrahabr.ru/company/mailru/blog/329494/
https://davidwalsh.name/php-generic
Илья
https://m.habrahabr.ru/company/mailru/blog/329494/
https://davidwalsh.name/php-generic
Тогда и в go есть дженерики, там даже в конце статьи есть обопщение Учитывая всё это, давайте рассмотрим код, который мы могли бы написать, будь дженерики реализованы в PHP...
Mike
🄽🄸🄺🄸🅃🄰
Ну на го есть рефлект
🄽🄸🄺🄸🅃🄰
Уводящий ответственность с компилятора на рантайм проверки программистом
🄽🄸🄺🄸🅃🄰
Но эт опасно как-то
Vasily
рефлект это немного не то
Vasily
этго не eval
Vasily
новый тип через него не создать и в структуру структры не изменить
Илья
ну, когда у тедя произвольные данные, то можно оперировать map ом, и тогда по сигналу перечитывать файлик и пересоздавать map
Ivan
Касательно перекомпиляции -да, я держу это в микросервисах и могу рестартить докер контейнеры. Сложно но можно. Но придется написать генератор этих структур и их обработки с формулами.
Касательно использования Lua, скажите куда копать. Я слышал но не пользовался
Задача не ясна до конца. Ну вот было в структуре 3 Инта, а теперь стало 4. Ну и игнорировать 4ый инт, пока не выкатится новая версия.
🄽🄸🄺🄸🅃🄰
ну пока не выгружу через git и docker новую версию сервиса четвертый (условно) инт и игнорится, ибо его некуда класть в структуре при заборе данных из бд
🄽🄸🄺🄸🅃🄰
ничего не падает. но вот если менеджерам взбрело поменять поля или убрать+добавить новых...
🄽🄸🄺🄸🅃🄰
то необходимо и на хранение новые структуры, и на математику
🄽🄸🄺🄸🅃🄰
и хочется реализовать инструмент, чтобы git не был нужен
🄽🄸🄺🄸🅃🄰
ну убрать как-то разработчика с этих рутинных задач
🄽🄸🄺🄸🅃🄰
кодогенерацию плохо знаю, но думаю туда копать
🄽🄸🄺🄸🅃🄰
а если новая формула расчета кстати, то сейчас это метод писать, в коде. Хочется какого-то интерфейса визуального описания, схемой, и из нее генерить реальную математику. Возможно тот же го код.
🄽🄸🄺🄸🅃🄰
Вопрос именно про то, сталкивался ли кто здесь с кодогенерацией или подобным
🄽🄸🄺🄸🅃🄰
скриптовые языки как lua тоже посмотрю,
🄽🄸🄺🄸🅃🄰
но математика идет на больших объемах данных, поэтому с go убрать не получится
Ivan
Ну выкат точно надо автоматизировать, хоть скриптом, хоть ci/cd.
Да, если там формулы, которые пользователи часто меняют, похоже скрипты самое оно.
🄽🄸🄺🄸🅃🄰
про выгрузку вопрос решится автоматизацией - это да.
🄽🄸🄺🄸🅃🄰
но как go подружить со скриптовыми
🄽🄸🄺🄸🅃🄰
не было опыта
🄽🄸🄺🄸🅃🄰
ну писал на php конечно
Ivan
В скрипты можно прокидывать методы обработки данных из которых уже пользователи составляют свои формулы.
🄽🄸🄺🄸🅃🄰
ну какой-то примитивный пример можете описать
🄽🄸🄺🄸🅃🄰
словами понятное дело)
🄽🄸🄺🄸🅃🄰
я просто картину архитектурную пытаюсь представить
Илья
ну смотри, есть поле - какие поля считать - туда водится цифра, чем угодно генеришь файлик, файлик выкладываешь на сборщик, сборщик кодогенерацией собирает новую версию и пушит на хранилище, гасит старый сервис - поднимает новый
Илья
звучит костыльно, но и задача у тебя такая :)
Илья
далее - детали, вместо файлика можно базу, вмсто довоза сервис отдельный, который из базы прочитает, и нужные сервис сам соберёт
Ivan
Ну есть 5 интов. В скрипте они доступны в виде некого массива. Чтобы узнать их сумму, можно сложить в цикле, а можно воспользоваться методом sum, который является биндом к go методу.
🄽🄸🄺🄸🅃🄰
не выйдет
🄽🄸🄺🄸🅃🄰
матматика не на пользовательском уровне
🄽🄸🄺🄸🅃🄰
а на очень большом объеме на бэке
🄽🄸🄺🄸🅃🄰
условно....1000.000 записей по 5 интов подвергаются 5 разным формулам рядом, и выдают 5 интов в результате
🄽🄸🄺🄸🅃🄰
это на бэке
🄽🄸🄺🄸🅃🄰
как тут скрипты подцеплять? в горутины пихать
🄽🄸🄺🄸🅃🄰
я вижу пока ток изврат с кодогенерацией и пересборкой в случае редактирования структуры сущности и формул
🄽🄸🄺🄸🅃🄰
в принципе это не частые операции
🄽🄸🄺🄸🅃🄰
но требуют как раз рутинной работы разработчика по добавлению там пары полей, там добавить в список, в базе пункт и флаг проставить, и тд...
🄽🄸🄺🄸🅃🄰
примитивно но завязано на разработчика
Ivan
Нужно определить, что именно в ваших вычислениях могут менять юзеры. Тогда и станет понятно, что и как кодогенерировать или скриптовать.
Пока слишком расплывчато.
🄽🄸🄺🄸🅃🄰
ну не юзеры а уполномоченные эксперты.
🄽🄸🄺🄸🅃🄰
подразумевается , что аналитик работал с системой работал, и понял в конце месяца, что надо добавить формулу для расчета новую. или отредактировать. А масса пользователей ее увидит завтра
🄽🄸🄺🄸🅃🄰
и будут по имени эту формулу применять, фильтруя данные через ползунки, но в сами расчеты доступа не имея
🄽🄸🄺🄸🅃🄰
думаю если построить модель с перезапуском сервиса после редактирования формулы в интерфейсе, скажем вечером ночью, то волне норм будет работать
🄽🄸🄺🄸🅃🄰
тесты прогонять, проверять все ли флаги везде ли проставлены, и выгружать новую версию
🄽🄸🄺🄸🅃🄰
но это все-еще внедрение в сам код
🄽🄸🄺🄸🅃🄰
это удручает
🄽🄸🄺🄸🅃🄰
хочется абстракции
Ivan
Да примеров много. Есть Ворд с макросами, есть prometheus с его языком метрик. Есть löve2d . Смысл везде один - в скриптах доступны некоторые методы, вызывая которые можно менять поведение основной программы. Если выделить библиотеку алгоритмов ваших вычислений, то эксперты смогут их компоновать в нужные формулы.
Vasily
кодогенератор с жесткой грамматикой, которая првоеряется в админке через JS
Axm
ребята, как жить в go без типизированных эксепшенов? коды везде возвращать?
Илья
++ пример на эту тему https://github.com/go-qbit/template, компилится в go
Daniel
предопределенные ошибки
Daniel
ну или коды
Daniel
ну или плакать и колоться
Axm
это же пиздец какой-то
Dmitry
ребята, как жить в go без типизированных эксепшенов? коды везде возвращать?
type ErrFoo struct {}
func (e *ErrFoo) Error() string { ... }
func NewErrFoo() *ErrFoo { ... }
Проверка через type switch
Илья
ребята, как жить в go без типизированных эксепшенов? коды везде возвращать?
в golang нет эксепшнов, а есть паника, и это очень дорого
Axm
type ErrFoo struct {}
func (e *ErrFoo) Error() string { ... }
func NewErrFoo() *ErrFoo { ... }
Проверка через type switch
я об этом думал, но там же везде интерфейс error. придется пихать повсюду свичи вот эти.
Daniel
это что?
это когда ты в своем пакете оформляешь несколько переменных типа, реализующего интерфейс error, и возвращаешь всегда их. и дальше switch,
Daniel
я об этом думал, но там же везде интерфейс error. придется пихать повсюду свичи вот эти.
а типизованный эксепшн без них обходится?
Dmitry
я об этом думал, но там же везде интерфейс error. придется пихать повсюду свичи вот эти.
Ну не везде, а только там где хочется именно обработать ошибку. Таких мест не так много
Axm
а типизованный эксепшн без них обходится?
логичный вопрос, но все же catch (...) лучше чем if err != nil { switch ...}
Axm
ладно, я понял принцип, спасибо вам!
🄽🄸🄺🄸🅃🄰
логичный вопрос, но все же catch (...) лучше чем if err != nil { switch ...}
можешь обертку catchErr(...) написать
🄽🄸🄺🄸🅃🄰
в чем проблема
Daniel
логичный вопрос, но все же catch (...) лучше чем if err != nil { switch ...}
пофиг абсолютно. типизованный эксепшн лучше только тем, что можно не все ловить, а кое что уедет выше по стеку само
🄽🄸🄺🄸🅃🄰
внутри любую логику реализовать