Не використовуйте Illuminate Support
tl;dr : Якщо Ви пишете framework agnostic пакет, не використовуйте illuminate/support.
Безліч framework agnostic Composer пакетів (PHP) залежать від illuminate/support, який включає хелпери і код загального призначення, що використовується в Laravel framework. А все тому, що цей пакет містить безліч чудових функцій типу array_get , а також чудові колекції.
Хелпери - чудова штука, але я не думаю, що розробники розуміють всі наслідки включення даного пакета до свого проекту. Усі бояться критики за винахід велосипеда, тому тягнуть 6000+ рядків коду, щоб самим не писати такий код
Пекло залежностей
Використовуючи illuminate/support (5.2) Ви підтягуєте у свій проект illuminate/contracts, doctrine/inflector, поліфіл для random_bytes, та mb_string. На щастя, дерево залежностей на цьому закінчується.
mb_string не стандартний PHP модуль, тому він не може бути встановлений на машині користувача. Якщо ви не працюєте з рядками, не варто змушувати користувачів перекомпілювати PHP тільки для того, щоб використовувати свій пакет. Можете використовувати stringy як хорошу альтернативу, він використовує поліфіл.
Конфлікт версій
Більше 6000 пакетів залежить від illuminate/support. Якщо хтось встановить Ваш пакет та інший, що включає illuminate/support, він повинен бути залежним від тієї ж версії, інакше вийде конфлікт. Побіжний погляд показує, що багато проектів все ще використовують версію 4.1.x.
Положення погіршується, якщо пакет використовується разом з Laravel або Lumen. Користувач не зможе оновитися раніше за Вас (і всі пакети, що використовують illuminate/support). Тепер Ви заважаєте користувачеві оновити свій фреймворк. Єдина альтернатива, використатинеобмежені діапазони на кшталт "5.2", але це досить погана ідея.
Глобальна область видимості
illuminate/support підтягує 52 функції у глобальну область видимості. Добре, якщо використовуваний фреймворк не використовує простір імен. Залежно не повинні забруднювати глобальну область.
Але ж хелпери прекрасні, чому б не використати їх? Деякі трансформери працюють не так, як очікується, а dd марний у терміналі. Але всі хочуть, щоб ці функції поводилися так, як хочеться, тому пхають їх у глобальну область.
Це, звичайно, невелика проблема, але сильно дратує коли пишеш код по 40+ годин на тиждень. illuminate/support має безліч часто використовуваних класів типу Collection, Request, Response, та App. Щоразу, коли я починаю набирати простір імен, IDE намагається імпортувати неправильну колекцію або марний фасад замість фактичного класу, який мені потрібний. illuminate/support включає цілий каталог класів які навіть не працюють за межами Laravel! Я гарантую, що Ви не використовуєте фасади в рамках framework agnostic, тому, будь ласка, припиніть їх тягнути в мій проект.
Критичні помилки
Зараз ваш пакет залежить від трьох різних пакетів, що не порушують SemVer. Чи варто ризикувати отримати такі ж проблеми, як із left-pad замість написання декількох рядків коду?
Націлювання на меншу кількість залежностей
Спробуйте використовувати якнайменше залежностей. Якщо подивитися на проекти від phpleague, то можна помітити, що всі вони мають малу кількість залежностей або їх взагалі не мають. Хороша практика – написати кілька невеликих допоміжних класів для 2-х чи 3-х функцій. Якщо не хочеться писати самостійно, скопіюйте функції, які Вампотрібні відповідно до ліцензії.
Якщо тестувати всі можливі версії, багато часу піде на налаштування конфігурації CI сервера, ніж написання свого власного коду та тестів для кількох допоміжних функцій.
Альтернативи
Якщо Вам потрібна тонна функціоналу, слід використовувати пакети замість того, щоб писати самому. Оскільки illuminate/support охоплює величезну кількість функціонала, нижче перелік тих, що можна використовувати для кожного конкретного випадку.
doctrine/inflector
Приведення слів до єдиного та множини. Це насправді залежність illuminate/support.
danielstjules/Stringy
Охоплює всі функції перетворення рядків. Використовувався в illuminate/support до версії 5.2.
dusank/knapsack
Робота із колекціями. Єдиний пакет, знайдений мною порівнянний з Laravel collections.
anahkiasen/underscore-php
Заміна функцій для роботи з масивами використовує точкову нотацію. Я не знаю, хорошої альтернативи, яка підтримує точкову без використання залежностей. Я просто пишу ванільний php для цього. У php7+ можна використовувати null coalesce operator замість array_get.
Хардкорна конфа за С++. Ми запрошуємо лише профі.
Читають зараз
Laravel – екосистема, а не просто PHP-фреймворк
Коментарі 35
Саме сьогодні бачив жарт у тему
> mb_string не стандартний модуль php > Не варто змушувати користувачів перекомпілювати PHP
Вважаю, мається на увазі, що PHP перекомпілювати для підключення модулів зовсім не потрібно, їх можна підключати і відключати за потребою. Більше того, mb_string досить популярний модуль у будь-якому випадку.
mb_string досить популярний модуль
Наразі активно використовуються emoji, і потрібно бути готовим до того, що такі символи трапляться у довільному тексті. Так що я припустив, що навіть англомовні розробники його використовують досить часто.
Автор і перекладач, мабуть, не знають, що illuminate/support це не лише 4 кілограми дієтичного м'яса хелперів, але ще й базові класи фреймворку типу сервіс-провайдера та менеджер, і що зі згаданих 6000+ пакетів більшість є саме пакетами для ларавелів.
Тобто, насправді повторне використання коду — зло? :)
Тоді взагалі не використовуйте фреймворки.
Я трохи відстав від життя, але навіщо так писати?
Адже «isset(expr)» по суті означає «expr!== null» (точніше, isset ще не показує помилки у разі неіснування змінної/індексу, тому насправді «@expr!== null»). Тобто. наведений вище шматок коду власне означає «@$arr[$k] !== null ? $arr[$k] : null», тільки більше заплутаний. Чому не просто написати «@$arr[$k]»?
Я розумію, якби було array_key_exists($k, $arr) ? $arr[$k] : null» - це, хоч і довго, але передає логічний зміст.
Часто пишу ось так:
І коротко, і логічний сенс цілком зрозумілий, як на мене.
Ну не на порядок повільніше:
Так, з порожнім хендлер якраз на порядок:
1.4448421001434 1.7445378303528 8.413987159729 10.663077116013
оновлюйтесь на php7 і припиняйте
Оператор придушення помилок – краще б його в PHP взагалі не було.
Про "??" безумовно згоден (мені незрозуміло навіщо взагалі вводили "?:" без середнього операнда замість того, щоб одразу ввести нормальний coalesсe; враховуючи, що в PHP помилка/відсутність індикується або поверненням null або поверненням false, PHP потрібнідва а-ля-coalesce оператора: coalesceNull(a, b) = a!==null ? a : b» та «coalesceStrictFalse(a, b) = a!==false? a: b»; перший вже нарешті ввели у вигляді "??", Тепер чекаємо другого).
Але про придушення помилок не розумію. Адже isset і "??" (а також empty) і так логічно (навіщось) включають придушення помилок. Що не так? По-моєму, було б краще, якби вони НЕ включали придушення помилок і одним оператором робилася рівно одна річ (писали б "@$arr[$key] ?? $default" або "array_key_exists($key, $ arr) $arr[$key] : $default»), без змішання сутностей.
і так логічно (навіщось) включають придушення помилок
ні, вони не "пригнічую помилки", вони просто їх не викликають. Ви просто перевіряєте їсти там значення чи ні.
Я це розумію. Але вважаю це неправильним. У сенсі: 1. Якщо вираз «expr» викликає помилку, то логічно, щоб будь-який вираз, що містить «expr» (у тому числі, наприклад, «isset(expr)» і т.п.) як операнда викликало ту ж помилку. Не викликати в такому разі помилку безглуздо — для перевірки без виклику помилки повинні використовуватися окремі конструкції (наприклад, «array_key_exists($key, $array)» замість «isset($array[$key])» і якесь поки що не існує «variable_exists ('varname') замість isset($varname) і т.д.). 2. Навіть якщо припустити, що існування якогось оператора «op(…)», який не викликає помилку для виразу «expr», що викликає виразку, логічно — то до isset все одно це не стосується. Так як isset двічі нелогічно - крім описаного в попередньому пункті, воно ще намагається виконати дві дії відразу: воно перевіряє наявність (змінної, індексу, поля) та перевіряє на нерівність null. Тобто. я б ще погодився використати якийсь оператор «exists(…)», який не викликає помилки для вкладеноговисловлювання - якби він просто перевіряв наявність.
Коротше кажучи. Я розумію, що isset швидше @/array_key_exists. Я розумію, що isset не є повним еквівалентом "@expr !== null" (крім різної поведінки у разі наявності обробників помилок, вона ще по-різному реагує на помилки у виразах, наприклад, «isset($arr[f()]) )» не придушить помилку всередині фукнції f, а «@$arr[f()]» - придушить). Але краще я втрачу кілька мікросекунд, ніж писати потворний код з isset.
Що ж до "??", то як я вже говорив вище, добре, що його нарешті ввели (не розумію, чому так пізно, зокрема пізніше потворного бінарного "?:"), погано, що на нього поширюється магія » у стилі isset/empty (краще б зробили array_key_exists вбудованим оператором для швидкодії) - але використовувати його мені, думаю, не доведеться, тому що я зав'язав з PHP задовго до появи навіть 5.6 версії.