Rude-PHP: библиотека с костылями и фенечками

отправить фич-реквесты разработчикам php не пытались?

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

В 2014-м году PHP-библиотека, недоступная через Composer — это большая редкость, заявка на историю неуспеха и лишние проблемы (с загрузкой, велосипедостроением и т.п.)

отправить фич-реквесты разработчикам php не пытались?

Не пытался. И вряд ли буду питать надежду на ответ если всё же сделаю реквест на некоторые фичи. Кодить мне надо сейчас, а не ждать релизов PHP6/PHP7/native-UTF8 и прочих утопий.

Дык это, пред вами - альфа-релиз, если вообще его так можно назвать. Если припрёт - закину и на Composer и на Pear. Вопрос пока в том, а надо ли оно? Об этом и тред.

Большая часть из всего этого, если не всё уже написано и красиво оформлено в виде библиотек. А еще эти библиотеки можно подключить простой командой: `composer require`.

https://github.com/ziadoz/awesome-php

https://github.com/MaciejCzyzewski/bottomline

https://github.com/danielstjules/SliceableStringy

https://github.com/eloquent/pathogen

https://github.com/filp/whoops

https://github.com/Andre-487/php_rutils

https://github.com/hassankhan/Syngr

Нужно только поискать

а надо ли оно

В таком виде — нет.

А debug, при наличии xdebug, который позволяет отформатировать вывод да еще и с подцветкой, ненужен.

Вобщем единственное, на что оно годится, так это для наколеночных скриптов, которые никогда не выйдут в свет.

Напротив: то, с чем я работаю в последние полтора года (два десятка сайтов, сорцы проекта от 2004г и старше, всё развитие пыха до текущих дней внутри + свои проекты) - всё это самопал. Самопальнейший велосипед со своим подобием MVC и любви к линю. И никто не возникает «уже написано», «никому не нужно», «никуда не выйдет». Уже вышло. Уже работает. Для людей.

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

Пажалста, поменьше «бе-бе-бе, нету Composer» и «бе-бе-бе, есть же БольшойЗдоровыйТолстыйКомбайнНаКучуКлассов - ниннада!» Помимо отсутствия вашего любимого менеджера либ и коммента «есть же венда, нафег линь?» ещё что-нибудь будет по конкретике? :-\

Дык это, пред вами - альфа-релиз, если вообще его так можно назвать. Если припрёт - закину и на Composer

Так в том-то и дело, что проще _начинать_ с Composer. Положил на GitHub, зарегистрировал на packagist.org, занимаешься спокойно разработкой и любому желающему пощупать проще одной командой вместо выкачивания, распаковки, прописывания include... В Composer процентов, эдак, 99 пакетов — именно пробные альфы :)

и на Pear

А это уже можно не делать, Composer его практически убил.

И никто не возникает «уже написано», «никому не нужно», «никуда не выйдет». Уже вышло. Уже работает. Для людей.

А конечному пользователю разве не всё равно на чём написано?

«бе-бе-бе, есть же БольшойЗдоровыйТолстыйКомбайнНаКучуКлассов - ниннада!»

А чем эта библиотека не «БольшойЗдоровыйТолстыйКомбайнНаКучуКлассов»?

Если те либы решают конкретную задачу и хорошо, то здесь охватывается всё, что только можно и порой не достаточно хорошо. Взять хотя бы ту же работу с базой данных. Многие, в том числе и я, скорее бы лучше осилили какую-нибудь доктрину или пропел. Тем более здесь завязка идет на mysqli. Т.е. пользователи остальных БД отпадают.

А еще мне непонятно, зачем столько классов со статическими методами, когда можно было бы просто организовать это в функции и запихнуть под соответствующие неймспейсы.

И наконец, любая уважающая себя open-source либа должна иметь юнит тесты. А здесь как я вижу могут возникнуть с этим проблемы.

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

Не мне конечно судить, но вряд ли. Есть куча фреймворков и библиотек с отличной документацией и сообществом, где все эти задачи уже были решены. И не надо снова говорить про «есть же венда, нафег линь?».

А лицензия, лицензия-то какая? Ни на сайте, ни в архиве не нашёл информацию о лицензии.

глобальный контекст, нет пространств имен?, ненужные функции...

Зачем?

Нужно ли поделие phpdoc, если есть doxygen?

Без лицензии еще меньше интересно.

и на Pear
Composer его практически убил.

нативные экстеншены

Нужно ли поделие phpdoc, если есть doxygen?

Я почему-то всегда думал, что в похапе негласный стандарт — phpdoc

Редко встретишь проект на похапе, который использует doxygen

https://github.com/FriendsOfPHP/pickle

нативные экстеншены

pecl же. И, соответственно, упомянутый выше pickle.

Придумал фичу: если платформа - windows, автоматически устанавливать cygwin/gentoo prefix и собирать экстеншены там. Взлетит?

Добавил саппорт Composer'a: мануал на сайте (линк в стартпосте) и на гитхабе: https://github.com/ThisNameWasFree/rude-php

Также впёр GNU GPLv3 для тех, кто подозревает всюду проприетарщину.

Всем радоваться два часа.

Может лучше BSD/MIT/Apache?

После GPLv3 это нельзя будет использовать при создании сайтов. В договоре на сайт всегда пишется, что все права на код переходят заказчику. (Не видел ни одного заказчика, который согласился бы на код, на который у него нет исключительных прав).

Я предпочитаю Beerware Licence, с ней как-то понятнее всё (:

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

Если в коде нечего патентовать, то BSD

Иначе http://www.apache.org/licenses/LICENSE-2.0.html

см https://news.ycombinator.com/item?id=3402450

Я бы выбрал Apache2, наверное, меньше головной боли.

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

AGPL.

В 2014-м году PHP-библиотека, недоступная через Composer — это большая редкость, заявка на историю неуспеха и лишние проблемы (с загрузкой, велосипедостроением и т.п.)

А потом к этому Composer прикрутят гуй... Что дальше? Мышкой программировать будете?

Не надо, в общем. Скачать и распаковать в проект - дело 30 секунд максимум, при этом контроль будет куда бОльший, чем через всякую хрень вроде Композера.

Толстопушечка.

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

у нас в Java есть Maven, не представляю как можно без этого жить

собственно Maven изначально был сделан в рамках веб-фреймворка Turbine, когда количество и сложность зависимостей стала такой, что проект еле-еле могли собрать сами авторы

В Java это норма, и там вся инфраструктура заточена на эти зависимости и их разрешение. А в мире PHP это инородные вещи. Попытка быть похожим на энтерпрайз там, где это не требуется в силу специфики применения языка. В итоге получается не облегчение трудоемкого процесса разработки, а опускание оного на уровень мышевозанья, да еще с привлечением лишних сущностей.

Конечно же существуют крупные проекты на PHP, но в них при обновлении библиотек принято подробно изучать не отвалится ли чего, зачастую на уровне чтения исходного кода. И Composer тут не помощник.

почему бы не допилить PHP до нормального ынтерпрайза? Заточить инфраструктуру, итэпэ

Конечно же существуют крупные проекты на PHP, но в них при обновлении библиотек принято подробно изучать не отвалится ли чего, зачастую на уровне чтения исходного кода.

Вот этого апельсинуса можно больше не слушать ибо 4.2

Потому что не требуется. У него своя ниша, и проекты делаются намного меньшего уровня типичного Java-проекта. Все это - оверхед и тешение своего ЧСВ тем, что тоже свои команды в консольке вводить можем, а не только код в IDE писать - со стороны выглядит круто же.

Вот этого апельсинуса можно больше не слушать ибо 4.2

Ты не проверяешь работоспособность крупного PHP-приложения после обновления либ? И кого тут слушать не надо?

Ты не проверяешь работоспособность крупного PHP-приложения после обновления либ? И кого тут слушать не надо?

Вообще-то либы предоставляют штабильный api на протяжении всей жизни конкретной версии(делаются только багфиксы).

В теории да. Но на деле, обновление либ вобще не ok. Если нет тестов на них и на связные компоненты.

Это проблема говнолиб без юнитов и быдлокодеров, которые не выносят новые/ломащие api фичи в отдельную ветку. В популярных проектах всё ок, даже при смене версии достаточно почитать UPGRADE.
Так что рекомендую пересмотреть свои зависимости.

Ты только что расписался в том, что пишешь крупный проект и не заглядываешь в исходники используемых библиотек. И если в Java это еще нормально, так как на скорость работы и потребление ресурсов там никто не молится, то в PHP использовать сей подход - как минимум писать тормозное неповоротливое говно. А потом, конечно же, имеем очередной сайт на Joomla с 700+ запросами в базу на одну страницу.

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

Забавно, но у меня наоборот — не было пока ни одного заказчика (а пару раз были ВЕСЬМА крупные :)), которые бы вообще как-то оговаривали вопрос лицензии кода. В двух текущих проектах у меня весь код вообще на bitbucket лежит :) Правда, в приватных репозитории.

Код, при чём не маленький. В самом жирном — 5300 файлов на 400 тыс. строк и 1768 коммитов.

Ok. А что делать с уникальным зависимостями, которым нет замены.

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

Ванга.

И если в Java это еще нормально, так как на скорость работы и потребление ресурсов там никто не молится, то в PHP использовать сей подход - как минимум писать тормозное неповоротливое говно.

Диванный теоретик.

А потом, конечно же, имеем очередной сайт на Joomla с 700+ запросами в базу на одну страницу.
700+ запросами в базу

А запросы видимо захаркожены внутри либы?
Всё с тобой ясно.

Страдать/поддерживать самому/лочить версию.

Ты не проверяешь работоспособность крупного PHP-приложения после обновления либ?

автотесты и интеграционные тесты проверяют целостность, сценарии проверяют тестировщики

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

Это само собой. Однако, еще раз, про PHP и его нишу.

Вариант 1: все добавляемое в проект проверяется вручную. Качество исходного кода, выбранный подход к решению задачи, много ли лишнего делает библиотека или строго то что нужно. Под какую версию PHP написано, долго ли протянет без обновления в условиях регулярного обновления самого PHP. Как у неё с безопасностью. Учитывая средний размер библиотеки на PHP, проверка одной может занять совсем немного времени. 1-10 минут.

Вариант 2: лепим все в одну кучу не заморачиваясь, получаем проект на Joomla. Или Битрикс.

В конвейерном производстве (сделал, сдал, остальное - проблемы тех бедолаг, кого найдут на саппорт) наиболее удобен второй подход, но... Шутки про PHP-разработчиков становятся весьма актуальны. Правда, они уже не волнуют тех, кто потешил своё ЧСВ набором умных команд в консоли, не так ли?

А вот когда годами, версию за версией делаешь свой проект, и нужно ощущение того, что держишь руку на пульсе, единственно верный вариант - первый. При желании вообще можно через диффы посмотреть, чего изменилось в новой версии либы.

Meanwhile in Russia...

Закончил допил класса строк для корректной работы с UTF-8:

$string_ASCII = 'ASCII string example';   # string(20) "ASCII string example"
$string_UTF8  = 'UTF-8 string πράδειγμα'; # string(31) "UTF-8 string πράδειγμα"

$result = string::length($string_ASCII); # int(20)
$result = string::length($string_UTF8);  # int(22)

$string_ASCII = 'ASCII string example';   # string(20) "ASCII string example"
$string_UTF8  = 'UTF-8 string πράδειγμα'; # string(31) "UTF-8 string πράδειγμα"

$char = string::char($string_ASCII, 14); # string(1) "e"
$char = string::char($string_ASCII, 15); # string(1) "x"
$char = string::char($string_ASCII, 16); # string(1) "a"

$char = string::char($string_UTF8, 14); # string(2) "π"
$char = string::char($string_UTF8, 15); # string(2) "ρ"
$char = string::char($string_UTF8, 16); # string(2) "ά"

$string_ASCII = 'ASCII string example';   # string(20) "ASCII string example"
$string_UTF8  = 'UTF-8 string πράδειγμα'; # string(31) "UTF-8 string πράδειγμα"

$count = string::count_chars($string_ASCII); # int(20) # Array
                                                       # (
                                                       #     [A] => 1
                                                       #     [S] => 1
                                                       #     [C] => 1
                                                       #     [I] => 2
                                                       #     [ ] => 2
                                                       #     [s] => 1
                                                       #     [t] => 1
                                                       #     [r] => 1
                                                       #     [i] => 1
                                                       #     [n] => 1
                                                       #     [g] => 1
                                                       #     [e] => 2
                                                       #     [x] => 1
                                                       #     [a] => 1
                                                       #     [m] => 1
                                                       #     [p] => 1
                                                       #     [l] => 1
                                                       # )

$count = string::count_chars($string_UTF8);  # int(22) # Array
                                                       # (
                                                       #     [U] => 1
                                                       #     [T] => 1
                                                       #     [F] => 1
                                                       #     [-] => 1
                                                       #     [8] => 1
                                                       #     [ ] => 2
                                                       #     [s] => 1
                                                       #     [t] => 1
                                                       #     [r] => 1
                                                       #     [i] => 1
                                                       #     [n] => 1
                                                       #     [g] => 1
                                                       #     [π] => 1
                                                       #     [ρ] => 1
                                                       #     [ά] => 1
                                                       #     [δ] => 1
                                                       #     [ε] => 1
                                                       #     [ι] => 1
                                                       #     [γ] => 1
                                                       #     [μ] => 1
                                                       #     [α] => 1
                                                       # )

... и далее по списку - всё 'UTF-8 compatible'. Единственный момент, который немного напрягает: костыль

if (preg_match('//u', $string)) { ... }

mb_detect_encoding($str, 'UTF-8', true)

Есть ли вообще шанс немного ускорить нативный валидатор (без унылых вариантов из комментов к php.net по типу «поискать BOM»)?

у нас в Java есть Maven, не представляю как можно без этого жить

Да просто: gradle. Правда он репозитории мавеновкие тоже юзать умеет.