кто нибудь занимался поисками двумерных таблиц подходящих параметров в потоке данных?

кто нибудь занимался поисками двумерных таблиц подходящих параметров в потоке данных?

звучит слишком абстрактно

есть большой файл а в нем таблицы. с примерно похожей структурой но разными значениями.

надо определить такие таблицы

Что за формат?

надо определить такие таблицы

типа схему выделить и потом искать соответствия?

да, пока решается регулярками + фильтр по результатам

но хочется готового решения

Что за формат?

текстовый файл

@mkusher поможешь?)

Не уверен, что пытаться делать типы в пыхе нужно

Не уверен, что пытаться делать типы в пыхе нужно

я тоже...

Чтобы сделать query builder надо ж не просто настоящие генетики завезти, а еще всякие операторы для работы с ними, всякие Pick, Omit, еще mapped types

Чтобы сделать query builder надо ж не просто настоящие генетики завезти, а еще всякие операторы для работы с ними, всякие Pick, Omit, еще mapped types

причем тут квери билдеры?)

причем тут квери билдеры?)

Ну либо я не понял что надо

тут хотя бы что-то лучше чем psalm сгодилось бы

Kotlin?)

ну то есть как по мне проблема тулов типа psalm/phan/phpstan - неверный подход к поиску компромисов на ложно-позитивные случаи (типа "не ну люди в 99% случаев проверяют есть файл или нет, и только потом file_get_contents юзают, накой проверять на false. Или накой проверять getType(): Type на нул, есть же hasType который 99% людей дернут.

ну то есть тула не должна идти на компромисы, но должна предоставить точку расширения для умных "подавителей" ошибок

хочешь - будет как у psalm, а хочешь - будет режим паранойи

ну то есть как по мне проблема тулов типа psalm/phan/phpstan - неверный подход к поиску компромисов на ложно-позитивные случаи (типа "не ну люди в 99% случаев проверяют есть файл или нет, и только потом file_get_contents юзают, накой проверять на false. Или накой проверять getType(): Type на нул, есть же hasType который 99% людей дернут.

Не, проблема в пыхе. Из-за грамотной стд объем работ по описанию всех случаев прилично так обгоняет даже мерзкий js, который два гиганта худо-бедно осиливают

Не, проблема в пыхе. Из-за грамотной стд объем работ по описанию всех случаев прилично так обгоняет даже мерзкий js, который два гиганта худо-бедно осиливают

но в целом большую часть работы сделали ребята из jetbrains)

я про тайпинги примитивные

но в целом большую часть работы сделали ребята из jetbrains)

Их анализатор уровня phan же

ну и опять же можно сделать точку расширения

которая позволит для array_map свой вывод типов мутить

да, будет по итогу раз так в 3-4 медленнее чем psalm. но зато гибко и более точно

ну то есть как по мне проблема тулов типа psalm/phan/phpstan - неверный подход к поиску компромисов на ложно-позитивные случаи (типа "не ну люди в 99% случаев проверяют есть файл или нет, и только потом file_get_contents юзают, накой проверять на false. Или накой проверять getType(): Type на нул, есть же hasType который 99% людей дернут.

Про file_get_contents, как ты представляешь себе нормальный тип для него?

Про file_get_contents, как ты представляешь себе нормальный тип для него?

string | false

А кто считает не так?

Т.е. это ж не проблема вывода, а проблема описания std?

psalm, phpstan. у них просто стринг потому что "не ну в 99% случаев там не будет false и нечего ругаться что ты не проверил"

Это проблема решается за 2 минуты форком)

в phpstorm стабах там string | false

Но это вообще не проблема

Но это вообще не проблема

psalm умеет только локальный вывод типов

меня это бесит

то есть вывод типов внутри замыкания но не с вызывающей стороны

Проблема с array_map в общем-то в variadic аргументах, но и это решается через описание конкретных случаев

array_filter([1, 2, 3], function ($i) { return $i % 2 === 0; });

вот попроще вариант

Окей, что здесь не так у psalm?

https://getpsalm.org/r/3f99ef2c0d

Кроме того, что ни одна тула не умеет в генерики?)

ну оно не может вывести тип $i

Потому что это сложная задача вообще говоря)

Для этого надо уметь в генерики

Для этого надо уметь в генерики

psalm чуть-чуть умеет в дженерики

https://github.com/vimeo/psalm/issues/762

psalm чуть-чуть умеет в дженерики

Давай будем честны)

вот с этой штукой может быть можно будет описать то что я скинул

Он просто вместо генерика почти всегда пихает any

Давай будем честны)

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

Делать точки расширения кмк это рак, потому что мы теряем весь смысл типов, как компактного явного языка описания интерфейсов

И начинаем использовать вместо этого компактного языка венец творения computer science, который хотели чуть-чуть подлечить этими самыми типами

Делать точки расширения кмк это рак, потому что мы теряем весь смысл типов, как компактного явного языка описания интерфейсов

Ну т.е. лучше юнит-тесты писать тогда

Он просто вместо генерика почти всегда пихает any

https://getpsalm.org/r/3dbfbc1b0e

не всегда

?

https://getpsalm.org/r/b02cf767c1

охереть, неужели

так, надо твой пример с котиками и собачками

https://getpsalm.org/r/b02cf767c1

А другой инт тоже нельзя ?(

Это похоже на проблемы тса, он тоже очень узкие типы выводит

Ну не настолько конечно

ну можно добавить /** @var Container<int> $data */

но чисто теоритический твой пример с котиками и собачками psalm сейчас захэндлит

ERROR: S client not available

сча потещу

но чисто теоритический твой пример с котиками и собачками psalm сейчас захэндлит

Дада, мечты)

Variance это настолько сложно, что лучше даже не начинать

В тс это делали года два

ммм

/** @var Container<int> $string */ $string = new Container('test');

оно даже это не смогло красненьким пометить

(

В тс это делали года два

И не сделали, просто убрали бивариантность аргументов функций(это было по сути эквивалентно выводу any)

Короче генерики(параметрические типы) это вершина айсберга

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

не сильно понимаю все же в чем проблема ADR

не сильно понимаю все же в чем проблема ADR

проблема ADR в отсутствии профита. pmjones предлагает тебе по классу на экшен. Это часто провоцирует людей пихать туда логику. Во всяком случае по моим наблюдениям.

а так как в его понимании Domain это "все что угодно что вы и так юзали" а Responder "что вы там раньше юзали для view" то в целом встает вопрос - а нахера тогда ты это придумал?)

имхо переименовывание компонентов никак людям не помогает по итогу.

было 3 херни где можно код писать - осталось 3 херни где можно код писать. Понимания когда надо юзать transactional script или дробить это еще на слои (application layer + domain layer + persistence layer) у людей не добавляется. Да даже то что мы с тобой обсудили уже (где ты все пытался с базами данных связать) немного говорит о том что проблема у ADR та же что и у MVC - типа "домен это про базу данных"

вместо этого лучше реально воспринимать твое приложение как некую цепочку адаптеров над приложением. И тем самым разделить уровни применения подходов - типа архитектура самого приложения отдельная история. Лучше распространять мысль что слои имеют свою стоимость, иногда они нужны а иногда нет. Есть масса других способов абстрагировать тот же контроллер от UI (за счет мидлваров) и реюзать в MQ или в CLI

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

(примерно то о чем Уди говорит)

хм...

я так понимаю что суть в том, что эти срезы как раз и находятся в зоне домена

ADR не решает проблему доменов, она для Web-application

кстати у меня как раз очень тонкие действия выходят, по размеру примерно как в том видео где сервисы размер сервиса

вернее его метода

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

кстати говоря о паттернах очень уж мне это напоминает command паттерн

кстати у меня как раз очень тонкие действия выходят, по размеру примерно как в том видео где сервисы размер сервиса

есть ли у тебя экшены где выходят одинаковые зависимости?

в смысле полностью?

таких нет

частично - да

не очень в это верю

но что бы что-то говорить нужно видеть код