Организация Linux Foundation представила (https://www.linuxfoundation.org/blog/2019/04/lf-forms-lamina.../) новый проект Laminas (https://getlaminas.org/), в рамках которого будет продолжена разработка фреймворка Zend Framework (https://framework.zend.com/), предоставляющего коллекцию пакетов для разработки web-приложений и сервисов на языке PHP. В том числе фреймворк предоставляет средства разработки с использованием парадигмы MVC (Model View Controller), прослойка для работы с базами данных, построенный на базе Lucene поисковый механизм, компоненты интернационализации (I18N) и API для аутентификации.
Проект передан под покровительство Linux Foundation компаниями Zend Technologies и Rogue Wave Software, вносившими основной вклад в его разработку. Linux Foundation рассматривается как нейтральная площадка для дальнейшего развития Zend Framework, которая поможет привлечь к разработке новых участников. Смена названия обусловлена желанием избавиться от привязки к коммерческому бренду Zend в пользу позиционирования фреймворка как проекта, развиваемого сообществом.
За технические решения в новом проекте будет отвечать управляющий комитет TSC (Technical Steering Committee), сформированный из участников команды Zend Framework Community Review Team. Юридические, организационные и финансовые вопросы будет рассматривать надзорный совет (Governing Board), в который войдут представители TSC и компаний-участники проекта. Разработка будет вестись на GitHub. Завершить все процессы, связанные с переводом проекта в Linux Foundation, планируется в третьем или четвёртом квартале этого года.
URL: https://www.linuxfoundation.org/blog/2019/04/lf-forms-lamina.../
Новость: https://www.opennet.dev/opennews/art.shtml?num=50530
За PHP будущее. Очень гибкий и мощный язык.
Если код на PHP генерировать из какого-нибудь Idris, то почему бы и нет. Тормознее уже не станет, а гарантии какие-никакие будут.:)
Каким бы был мир без пхп? На чём писали бы сайтики, на C+CGI?
на parser3 - http://parser.ru
Ого! Оно живое ещё? Я когда-то давно читал про это чуть-чуть.
скорее мертвое - Paf, главный писатель второй и третьей версий, давно уже не с ними, moko@ давно уже неинтересно, в своих разработках они им уже давно не пользуются, тянут по инерции, если патч прислать - может быть что поправят.fcgi не осилили, поскольку самим им не надо, современные nosql ниасилили, кроме мемкэша, который сделан наспех и неправильно (нет cas, который приходится заменять кривыми и ненадежными костылями), собирается на современных системах уже со скрипом, поскольку такой c++ десять лет уже немодно.
а жаль, да. Половины типовых уязвимостей гуанокода на пехепе удалось бы избежать при ничуть не более сложном для понимания языке, если бы он не застрял навеки в 2005м году.
>Поддерживает UTF-8, Windows-1251 и KOI8-RЕсли есть UTF-8, то зачем остальные две?
>Оптимален для написания «Hello, world!»
И это самое ценное. :)
На том же, на чём писали — Perl, Python, Ruby, JavaScript (только не надо мне писать, что node.js недавно изобрели, до него было как минимум две реализации серверного JS — нетскейпа и MS).
Вполне возможно, что в мире без пыха его место занял бы перл. CMS для него были уже тогда, поддержка апачем в виде mod_perl... не помню, но, возможно, во время выхода PHP3 уже и была.
"Сегодня в завтрашний PHP не все могут смотреть. Вернее, смотреть могут не только лишь все, мало кто может это делать."
> За PHP будущее. Очень гибкий и мощный язык.Кстати, да! ...ебилдов и PHP-зенд-EBPF в ядре.
Веб-конфигуратор ядра грядёт, .... Вииииижу!
Zend решили таки дропнуть своё монструозное поделие, и заняться наконец разработкой именно самого PHP?
Давно пора, на самом деле. Любители пошли в ларавель, а профи в симфони. Остальное стагнирует.
Многие профи тоже пошли в Laravel. Кому-то же надо разгребать всякое написанное любителями и внезапно взлетевшее. :-)Вообще после опыта с Symfony хороший код можно писать и на Laravel. Фреймворк не сильно мешает. Самое сложное тут - обучить коллег делать не так, как они привыкли.
К сожалению, разработкой Zend Engine (по сути, "ядра" php) они тоже решили не заниматься: http://zsuraski.blogspot.com/2018/10/the-future-of-zend-engi...Но как минимум Дмитрий Стогов (уже вне Zend) активно занимается разработкой JIT-компилятора для PHP8+. Уж не знаю, спонсирует кто-либо эту работу, или он это делает из любви к искусству, но прогресс заметный.
Не так немножко. Как с мусклом и марией почти... Зенд купила какая-то Rogue Wave, со всеми вытекающими. Теперь ключевые фигуры оттуда слились, фреймворк сбрасывают, потому что малой кровью его разрабатывать невозможно, и скорее всего займутся собственно пыхом. Вопрос только, не получится ли в итоге как с мускулом - двух веток.
двух? Чего это двух? У нас уже есть совершенно несовместимые пятая, 7.2 и 7.3, и уже почти есть совсем несовместимая 8, не говоря уже о фейсбучековой отдельно-несовместимой реализации.Будет еще парочка, подумаешь...
Эээээ?В чём несовместимость-то? Единственный существенный разрыв был между 5.2 и 5.3, где изменилось поведение передачи аргументов по ссылкам. В остальном несовместим только унылый говнокод, если писалось аккуратно - переезд между 5.x и 7.x вообще без проблем.
У меня один здоровый проект прошёл насквозь через 5.3->5.4->5.6->7.0->7.2->7.3, с несущественными модификациями. По хорошему, там сейчас надо делать рефакторинг + чистить код под 7.x, но это уже отдельная задача, на совместимость она не влияет.
А мини-фреймворк (~120K кода) внутри этого проекта существует и адаптируется с 4.0, но это уже другая история, и изменений там было побольше.
писалось "аккуратно" - на машине времени подвозили каждый день новые изменения через пять лет, чужие модули и тем более фреймворки не использовали и т д, ага.> с несущественными модификациями
это для тебя они "несущественные" - там поправить, тут подпилить, здесь подогнуть.
А если бы это был не твой личный проект - он просто разваливается, и ты идешь искать в мегабайтах кода и тысячах файлов, откуда приехал не тот тип аргумента.Ну или плюешься и достаешь из заначки давно неподдерживаемую кривособирающуюся старую версию, всегда так и делаю.
Хуже, когда какой-нибудь урод типа битрикса заявляет что с сегодняшнего утра поддерживает только 7.2 (совместимость? Какая такая еще совместимость?), апдейт безопасности надо ставить, а у тебя тонна локального кода производства неведомых хохлоаусорсеров, которых, разумеется, давно след простыл, и он, разумеется, не работает.
Это просто разные подходы. Писать говнокод, хрен знает какими студентами, а потом превозмагая его развивать и поддерживать.
Вообщем есть люди у которых всегда полно работы, чтобы они не делали. Они выглядят очень важными и незаменимыми. Главное не разбираться что там действительно происходит, нервы целее будут.
ну ты-то конечно пишешь не такой код, гораздо лучший.жаль что его никто не видит и не бежит платить тебе грузовик денег, одни студенты кругом, да?
LOL, по себе не меряй.
Ну там мегабайты кода и пара сотен файлов - плодить тысячи файлов по одному на каждые 50-100 строк в PHP могут только идиоты, впрочем, современные "фреймворки"... oh shi...При переходе с 5.6 на 7.0 да, несколько тестов развалилось, но правки кода были минимальными, и в основном касались deprecated функционала.
Основной проблемой было изменение поведения передачи аргументов по ссылке, если раньше можно было отправить вычисленное значение, и любое изменение аргумента внутри функции тупо сбрасывалось при выходе, то теперь пришлось явно отправлять ($u1 = (вычисление)), чтобы оно не материлось, всё остальное перенеслось без проблем. Для 7.2 пришлось почистить break / continue кое-где, но в общем это и всё.
> плодить тысячи файлов по одному на каждые 50-100 строкНе совсем понятен сарказм. В больших проектах на много удобнее иметь на один роут _один_ файл в котором _один_ обработчик. Есть вероятность что баг в одном файле сломает один роут, а не пол проекта. Смотреть историю изменения на порядок проще. И т.д.
С роутами понятно. Но ребята совсем о***евают, лепя один файл на один мини-класс, и плодя сотни этих классов. В итоге загрузка этого одного роута имеет 200%+ оверхеда к полезной работе на обработку этих файлов на каждый запрос, а один баг в одном файле всё равно ломает полпроекта, потому что тянется с каждого роута.
> лепя один файл на один мини-класса как без этого обеспечить нормальную автозагрузку?
> плодя сотни этих классов
single responsibility - это хорошо и надёжно.
> 200%+ оверхеда к полезной работе на обработку этих файлов на каждый запрос
настройте Opcache
>> лепя один файл на один мини-класс
> а как без этого обеспечить нормальную автозагрузку?Элементарно. Возможности создания карты классов никто не отменял.
Более того, карта классов автоматизирует сборку - в исходниках может быть один файл на класс, но дальше они при тесте или деплое по этой самой карте упакуются в разумные и настроенные как раз таки responsible person блоки. В итоге вместо сотни вызовов автолоудера на запрос будет 10.
То, что этого не делают, говорит только о низкой в целом квалификации и полном непонимании схемы работы интерпретатора PHP.
> настройте Opcache
Для своих внутренних проектов - легко. А теперь расскажите про opcache шаред хостингам, где очень любят размещаться пользователи этих монструозных поделок :D Мы кстати сами - один из тех редких шаредов, кто реально применяет opcache.
> современные "фреймворки"... oh shi...я и говорю - главное, не пользоваться никакими фреймворками и вообще никаким чужим кодом.
я вот тут в копр...корпоративной разработке поправил пару очевидных строк - оно даже и запустилось, до первой страницы. Но дальше там smarty, выкрасить и выбросить, ремонту это не подлежит.
мегабайты кода - это очень маленький проект - вот тот что со смрадью - 800 мег именно кода (включая саму смрадь), крошечный внутрикорпоративный проектик, 1/100 от того что тут вообще есть.
Весь этот код автоматически нагенерён, надеюсь? :D
не весь, надеюсь - кто-то же написал то, что его генерит?хотя хрен его знает, конечно, я их не видел. Может это и не люди совсем?
Насчёт битриксов и прочего хлама - да, может выморозить, особенно если хостинг внешний, и версию пыха так просто не сменить. Если свой - гонять две версии на одном сервере проблем нет, особенно после FPM, да и без FPM можно.
версию-то я поменяю - умище, умище-то куда девать? В смысле - чинить-то его теперь кто будет после смены версии? Нет, очередного украинского аутсорсера мне там даром не нать, я еще за предыдущими не весь навоз вывез.
В смысле кто? 800 мегабайт кода - так, мелочь, 1/100 от ваших внутренних проектов, а битриксы починить некому? Что-то не сходится в ваших показаниях :)
битрикс (теперь) мой личный (в смысле, та хрень что на ем), конторские разработчики это править не будут.А я скорее выкину его вместе с пехепе - все равно там уже только мертвые с косами. look&feel того что еще живо можно и на коленке воспроизвести.
Просто весьма показательно, что грабли и с битриксом, понаслесаренным на от...сь, и с корпоративным кодом, который, по идее, должны были писать грамотно и аккуратно (да наверное так и есть, раз он не лопнул еще) - примерно одинаковые.
Да, при переходе на 7.x ещё в другом месте (уже другом проекте) наступили на то, что исчез драйвер MSSQL, но поскольку подложка микрофреймворка всё та же - пересадили на нативный мелкософтовский драйвер без особых проблем.
пиши приложения а не фреймворки
А чё не под Апач?
Это же PHP, а не Java
> PHPКогда оно уже сдохнет? Не язык, а куча сломаных костылей.
Чем современный PHP принципиально отличается от того же питона? От джавы? От любого другого ЯП общего назначения? По пунктам, пожалуйста.
Запили event loop на php
Легко. Выбирай, что больше нравится: https://pecl.php.net/packages.php?catpid=44&catname=Event
Делать из буханки хлеба троллейбус? Можно. Но зачем? В PHP совершенно другая модель программирования, не надо тянуть туда костыли классического типа.
Если сравнивать с Java - лично мне дженериков не хватает. В принципе, это компенсируется хорошей IDE со статическим анализатором и phpdoc-хинтами.Стандартная библиотека, конечно, объективно кривая, но за 15 лет я привык :-)
> Чем современный PHP принципиально отличается от того же питона?Уродством синтаксиса. Сравни:
if ($object.method()==1) {
echo("Hello");
}if object.method():
print("Hello")Что режет глаз?
НЕХ в первом примере. Это на каком языке?
> НЕХ в первом примере. Это на каком языке?Точно, ПЫХ ещё более уродлив:
if ($object=>method()==1) {
echo("Hello");
}
if ($object.method())
echo 'Hello';
if ($object()) {
echo 'Привет!';
}Можно и так, вам просто не хватает образования.
вашего образования, похоже, не хватило даже на понимание, что там проверялось совсем другое условие.
Режет глаз второе. Особенно отсутствие скобок вокруг условия, отсутствие then - ":" вместо такового, отсутствие символа завершения ";". Ну и лично меня ещё бесит бейсиковый print, но это уже десятое. И кое что остаётся за кадром: значимые пробелы - то есть при неудачном копировании всё это разъедется.if ($object->method() == 1)
echo("Hello");Вот так нагляднее.
Ничего ты не понимаешь! Это же фича, а не баг. Любой питонер тебе это скажет.
Если кратко: чем больше узнаю питон, тем javascript все больше кажется нормальным языком.
> Чем современный PHP принципиально отличается от того же питона? От джавы? От любого другого ЯП
> общего назначения? По пунктам, пожалуйста.только в нем можно внезапно-исполнить подвернувшийся чужой код при попытке просто проверить существование файла ;-) Попробуйте-ка добиться такого на жабе!
Не можно, нужно phar:// к названию файла препендить. Ну, если кто-то из юзеринпута не валидирует имена файлов и не меняет их перед записью - я ему сочувствую изначально, phar-десериализация там далеко не самый страшный вариант.
я уже устал у тебя спрашивать, что неправильного в моем файле phar://mycat.jpeg ?Если кто-то не вылезает из милой десяточки, у меня для него неприятный сюрприз - это валидное имя.
> Ну, если кто-то из юзеринпута не валидирует имена файлов и не меняет их перед записью
сверяясь с данными из будущего, какие еще волшебные буквы, ВНЕЗАПНО разработчикам взбредет в голову интерпретировать как код?
я и говорю - унылое г-но эта ваша жаба, совершенно неинтересно на ней программировать. (у пихона тоже нет такого функционала, но в них я верю, они наверняка уже заняты изобретением еще лучших возможностей что-нибудь внезапно поисполнять)
Что неправильного? Наличие протокольного префикса, его как бы в юзеринпутфиленаме быть не должно, не? И вообще не должно, если ты не хочешь файл как phar трактовать. А если хочешь - какие претензии? Как написано, так и исполняется.
откуда ж я знал десять лет назад, что это протокольный префикс?
у меня это имя каталога. С двоеточием на конце. Там рядом еще собачка и цветочек.А удвоить / - в общем-то, много где можно совершенно случайно.
И вы юзеру позволяете шариться по вашей файловой системе с : и /, конечно же, прямо из инпута. Ну сочувствую, чего. У нас этого допустим быть не может, потому что быть не может by design - пространство имён файловой системы 100% оторвано от юзеринпута.
мы можем позволить юзеру создавать подкаталоги, да.
Но языки приходится использовать без странностей.> потому что быть не может by design - пространство имён файловой системы 100% оторвано от
> юзеринпутану правильно, ведь файловая система - она для чего угодно, только не для хранения файлов - в том числе, со времен dos2.0 - иерархического. Будем криво-косо дублировать ее функционал на нескучных язычках, а то...а то они выполнят файл как код при попытке всего лишь поинтересоваться, есть ли он вообще на диске. Так победим!
Почему? Всё прекрасно раскладывается по каталогам и ещё шардится по пачке нод. Но вот юзерские имена файлов - все в БД, там юзер может хоть "у попа была собака" писать, и собственную структуру каталогов иметь, движок всё равно разложит так, как оптимально движку, юзер этого просто не видит.
> Но вот юзерские имена файлов - все в БДну и зачем? Теперь вместо одного поиска нужны два - один в дереве фс, другой в бд.
Теперь можно проиметь файл с диска, но сохранить в бд, к удивлению юзера, или наоборот - потерять запись, но из-за каких-то причин не успеть удалить файл.Теперь будем писать к этому свою "fsck", которая попытается устранить неконсистентность, да?
На самом деле, проблема не в phar, а в unserialize. Phar это еще один извращенный способ эксплуатировать unserialize magic. Java Deserialization Vulnerability имеет ровно ту же природу. Сама по себе универсальная (де)сериализация, позволяющая создать объект любого класса (и триггернуть все связанные с этим сайд эффекты) - так себе идея.
Начиная с 7.1 можно в ансериалайз воткнуть опцию allowed_classes=false, но вообще передача юзерских данных в ансериалайз - зло.
по-моему проблема в подмене файлового апи uri'шным вместо изобретения отдельного, в котором нет места, к примеру, проверкам существования.
Зато так проще, ага.
Стримовым. Там кроме URI можно много чего весёлого нафигачить, и это очень удобно.
Не, ну сама идея everything is a file вполне юниксвейная, plan9, вот это все.
> Не, ну сама идея everything is a file вполне юниксвейная, plan9, вотне, тут как раз etherything is a stream. А что нужно иногда просто работать с файлами - да зачем вам, в самом-то деле.
> не, тут как раз etherything is a streamну так как в plan9 как раз
Ну и чужой код исполнить не получится - только зарядить объекты из исходного кода. Вот если в этих объектах где-нибудь eval - тогда уже интереснее, а за eval в коде надо нещадно ***ть морально до полного понимания. Да, бывают и интереснее eval'а места, но это уже очень редкость и специфика - и, повторюсь, сначала надо phar:// запрепендить, что при корректной организации user data storage уже нереально.
CMS на пыхе без eval покажите мне. Хочется посмотреть на это чудо генной инженерии.
а зачем там вообще eval?делаешь
$my_class = "\Namespace\Foo";
$my_obj = new $my_class;
и будет тебе счастье.
Как зачем? Быдлошкололокодеры без eval - никак.
Современный PHP относительно неплох, как язык, но всё вот это легаси... особенно его стандартная библиотека, начиная от элементарных строк, массивов и так далее.. это же кошмар какой-то.. Это ещё не было речи про легаси-код, хотя, лучше не надо
Так пиши себе в столик на любимом тобой язычке, кто ж тебя пых-то трогать заставляет.
Пользователи довольны. Хорошая новость. Уже вторая на сегодня. Хороший сегодня день.
Ура! Лучший фреймворк спасен! А я уже думал все, закопали. Развитие остановилось. А тут на тебе, сам LF! Огромное спасибо!
>Ура! Лучший фреймворк спасен! А я уже думал все, закопали. Развитие остановилось. А тут на тебе, сам LF! Огромное спасибо!Смищно.