будет лишний варнинг если индекса нет.
Прелесть библиотеки в автодополнении, жмёшь контрл + пробел и выбираешь вариант, на клавиатуре, за секунду, обычно IDE подставляет первыми вариантами то что тебе надо и для того что бы набить код уходит минимум времени, часто пишешь на одном дыхании.
Можно писать так:
и не надо ни каких ребусов решать с "??" и когда дочитал всю строку выражения не надо вспоминать что результат надо привести к типу который был указан в начале строки.
Всё делается линейно:
$val1 =
// в $val1 запиши значение следующего выражения
$vars
// из массива $vars
->get('key1')
// возьми элемент с индексом 'key1'
->default($def1)
// используй значение по умолчанию $def1
->int();
// приведи значение к int
Мне такой код легче заходит, библиотека написана для себя и мне не жалко ей поделиться, кто может обойтись без неё обходитесь, кто же вас неволит?
Смысл использования ArrayHandlera в том что по get() он выдаёт ValueHandler у которого есть методы для приведения типов.
Можно упрощать массив с помощью array_column(), но для типобезопасности всё равно надо создать экземпляр ArrayHandler.
Смысл использования библиотеки в интеграции функционала.
Можно писать $number = (int)@(vars['key']) всегда на выходе будет int и ни когда не будет ошибки "ключ не найден", но как то не очень нравиться мне такой код.
Идея с классами вполне себе альтернативный вариант, но надо гетеры выписать, это чуть сложней чем просто одна строка get('side_numbers')->int().
И в базу писать массив как то проще, с классом придётся этот массив предварительно создать и наполнить.
array_column() — да, спасибо за подсказку, можно использовать внутри simplify().
Короткий срок жизни кода это когда нам надо завести в базу исходные данные которые позже будут обработаны с помощью SQL.
Моя последняя задача была о том что бы из csv залить в базу точки продаж и с помощью описательного адреса для каждой точки определить гео координаты.
А дальше конечные пользователи CRM с точками продаж должны работать через админку Битрикса.
И кругом у тебя массивы — csv — массив, ответ геокодера — массив, ответ ORM Битрикса — массив.
Соответственно с обработкой этих данных и появлялись новые требования к этой библиотеке и исходя из них развивался функционал.
Последний пример кода на мой вкус очень наглядный.
Изложение конечно скорее развлекательное чем информативное. Но не вижу смысла, мне кажется ни кто не кинется разворачивать либу с помощью композера и тыкать в неё острой палкой, что бы понять на что она способна.
В репозитонии для каждого метода показаны примеры работы, ещё более подробно описано в тестах, было бы желание разобратья.
Вообще конечно статья для получения обратной связи, потому что я конечно доволен как слон, но я всего не знаю и опыт у меня только личный, может быть есть готовые инструменты? Может быть нужен совсем другой подход?
Не знаю. Было бы интересно послушать ответы на эти вопросы.
PDO::FETCH_CLASS — Зачем такие сложности? Специфика задач подразумевает очень короткий срок жизни кода. И даже безотноситено этого, как использование PDO::FETCH_CLASS гарантирует мне соблюдение типов?
Автоматического приведения типов не случиться, присвоения значений по умолчанию тоже.
Писать каждый раз логику? вот я и написал библиотеку один раз что бы использовать везде. Будь у меня источник данных PDO или .csv, или json из какого то API, не важно какой источник данных, если он сводиться к массиву то с помощью своей библиотеки у меня всегда на выходе будут переменные строго заданных типов.
FETCH_COLUM по этой же причине не всегда применим, по этой же причине методу simplify можно отдать массив с нужными нам индексами и он вернёт только заданные колонки, это нужно когда мы из .csv файла парсим не все колонки, а только две три.
Спасибо за ссылку.
Посмотрел на коллекции. Весь функционал коллекций это работа с массивом. Но основное назначение моей библиотеки это работа со значением.
Во первых понять определено оно или нет.
Во вторых получит значение строго заданного типа, либо получить значение по умолчанию.
Этот функционал не сложно сочинить самому, занимает он пять строчек кода, но когда тебе это надо сделать для 5 — 15 колонок, тебе очень хочется упихать обработку одной колонки в одну строчку и не страшно если это будет цепочка вызовов, и не страшно что под капотом будет работать не 5, а 500 сторок кода, это всё не имеет значения когда тебе просто надо накидать код, который жить будет от силы неделю, а скорей всего уже завтра утратит свою актуальность.
божественно!!!
самое лучшее объяснение качества программных продуктов как изделия, и качества программного кода самого по себе.
Идеальный код нужен только даром, бабки заплатят за самый мимально хоть как то работающий, только что бы сдать проект, а как с ним жить потом, это проблемы заказчика, и немного авторов ТЗ.
+1, присоединюсь, было бы интересно послушать обзор, когда сам с dbForge работал 4 года назад, там было пара багов которые делали работу не возможной, может быть сейчас уже исправили?
Сама по себе IDE очень приятная.
У автора определённо литературный талант, прочитал на одном дыхании, во многом узнавал себе.
Автор, да и фиг с ним что твой идеальный код ушёл в утиль, за то ты можешь собой гордиться что ты смог проделать титаническую работу и существенно повысить качество этого кода.
У тебя появился ОПЫТ, ты применил НАВЫК, который сможешь с меньшим успехом применить в более везучем проекте.
Автор ты молодец!
Композер подключить и пакет вытянуть (либу) это две строчки в командной строке. Во время работы скрипта Композер ни чего лишнего не грузит, кроме автозагрузчика.
То есть что я хочу сказать что Композер это не утяжеляет проект ни разу.
что в нём плохого?
задание хорошее для работодателя если он хочет оценить соискателя с минимальными затратами времени для соискателя. Если у вас другое мнение, то я вам своё не навязывал.
будет лишний варнинг если индекса нет.
Прелесть библиотеки в автодополнении, жмёшь контрл + пробел и выбираешь вариант, на клавиатуре, за секунду, обычно IDE подставляет первыми вариантами то что тебе надо и для того что бы набить код уходит минимум времени, часто пишешь на одном дыхании.
Можно писать так:
а мне нравиться писать так:
и не надо ни каких ребусов решать с "??" и когда дочитал всю строку выражения не надо вспоминать что результат надо привести к типу который был указан в начале строки.
Всё делается линейно:
Мне такой код легче заходит, библиотека написана для себя и мне не жалко ей поделиться, кто может обойтись без неё обходитесь, кто же вас неволит?
Смысл использования ArrayHandlera в том что по get() он выдаёт ValueHandler у которого есть методы для приведения типов.
Можно упрощать массив с помощью array_column(), но для типобезопасности всё равно надо создать экземпляр ArrayHandler.
Смысл использования библиотеки в интеграции функционала.
Можно писать $number = (int)@(vars['key']) всегда на выходе будет int и ни когда не будет ошибки "ключ не найден", но как то не очень нравиться мне такой код.
Идея с классами вполне себе альтернативный вариант, но надо гетеры выписать, это чуть сложней чем просто одна строка get('side_numbers')->int().
И в базу писать массив как то проще, с классом придётся этот массив предварительно создать и наполнить.
array_column() — да, спасибо за подсказку, можно использовать внутри simplify().
Короткий срок жизни кода это когда нам надо завести в базу исходные данные которые позже будут обработаны с помощью SQL.
Моя последняя задача была о том что бы из csv залить в базу точки продаж и с помощью описательного адреса для каждой точки определить гео координаты.
А дальше конечные пользователи CRM с точками продаж должны работать через админку Битрикса.
И кругом у тебя массивы — csv — массив, ответ геокодера — массив, ответ ORM Битрикса — массив.
Соответственно с обработкой этих данных и появлялись новые требования к этой библиотеке и исходя из них развивался функционал.
Кому надо разберётся. Или вообще публиковать ни чего не надо если стиль излржения кому то может показаться не достаточно доходчивым ?
Последний пример кода на мой вкус очень наглядный.
Изложение конечно скорее развлекательное чем информативное. Но не вижу смысла, мне кажется ни кто не кинется разворачивать либу с помощью композера и тыкать в неё острой палкой, что бы понять на что она способна.
В репозитонии для каждого метода показаны примеры работы, ещё более подробно описано в тестах, было бы желание разобратья.
Вообще конечно статья для получения обратной связи, потому что я конечно доволен как слон, но я всего не знаю и опыт у меня только личный, может быть есть готовые инструменты? Может быть нужен совсем другой подход?
Не знаю. Было бы интересно послушать ответы на эти вопросы.
Главное что бы код был ок. А пресс релизы пусть пресс секретари пишут и прочие контент менеджеры. Каждоиу своё
PDO::FETCH_CLASS — Зачем такие сложности? Специфика задач подразумевает очень короткий срок жизни кода. И даже безотноситено этого, как использование PDO::FETCH_CLASS гарантирует мне соблюдение типов?
Автоматического приведения типов не случиться, присвоения значений по умолчанию тоже.
Писать каждый раз логику? вот я и написал библиотеку один раз что бы использовать везде. Будь у меня источник данных PDO или .csv, или json из какого то API, не важно какой источник данных, если он сводиться к массиву то с помощью своей библиотеки у меня всегда на выходе будут переменные строго заданных типов.
FETCH_COLUM по этой же причине не всегда применим, по этой же причине методу simplify можно отдать массив с нужными нам индексами и он вернёт только заданные колонки, это нужно когда мы из .csv файла парсим не все колонки, а только две три.
Спасибо за ссылку.
Посмотрел на коллекции. Весь функционал коллекций это работа с массивом. Но основное назначение моей библиотеки это работа со значением.
Во первых понять определено оно или нет.
Во вторых получит значение строго заданного типа, либо получить значение по умолчанию.
Этот функционал не сложно сочинить самому, занимает он пять строчек кода, но когда тебе это надо сделать для 5 — 15 колонок, тебе очень хочется упихать обработку одной колонки в одну строчку и не страшно если это будет цепочка вызовов, и не страшно что под капотом будет работать не 5, а 500 сторок кода, это всё не имеет значения когда тебе просто надо накидать код, который жить будет от силы неделю, а скорей всего уже завтра утратит свою актуальность.
самое лучшее объяснение качества программных продуктов как изделия, и качества программного кода самого по себе.
Идеальный код нужен только даром, бабки заплатят за самый мимально хоть как то работающий, только что бы сдать проект, а как с ним жить потом, это проблемы заказчика, и немного авторов ТЗ.
Сама по себе IDE очень приятная.
Автор, да и фиг с ним что твой идеальный код ушёл в утиль, за то ты можешь собой гордиться что ты смог проделать титаническую работу и существенно повысить качество этого кода.
У тебя появился ОПЫТ, ты применил НАВЫК, который сможешь с меньшим успехом применить в более везучем проекте.
Автор ты молодец!
То есть что я хочу сказать что Композер это не утяжеляет проект ни разу.
ссылку забыли подставить
задание хорошее для работодателя если он хочет оценить соискателя с минимальными затратами времени для соискателя. Если у вас другое мнение, то я вам своё не навязывал.