Pull to refresh

Comments 43

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


С обратной совместимостью согласен отчасти (все нынешние библиотеки объявить как depricated в 5.6, а в 6 убрать). Но вот с производительностью — только если имеется в виду прежде всего производительность программиста, изменения синтаксиса, направленные на это. А если направленная на увеличение rpm ценой отказа от BC, без улучшения простоты кода — на фиг надо. Вон HipHop есть, Phalcon и Yaf.
UFO landed and left these words here
Если бы PHP без ущерба синтаксису (ну… с маленькими доработками бардака в именованиях функций) стал чем-то вроде NodePHP, он бы от этого только выиграл.


Вряд ли. Постоянные соединения не являются развитием tcp или http-протокола. Это просто еще один способ их использования для специфических задач. А PHP и так уже слишком универсален (за что тоже приходится платить) и если туда сейчас еще «привсовывать» разных фишечек — то думаю новых версий мы вообще никогда не увидим :-).
UFO landed and left these words here
PHP — это платформа для разработки веб-приложений. Я уж не буду рассматривать какие-нибудь phpQT или что там есть, сомневаюсь, что на них кто-то что-то путное написал. И поэтому PHP, наверное, надо рассматривать как средство решения узко специализированных задач.

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


Не понимаю, что вы хотите оставить от PHP?

Websocket это в первую очередь — работающий на порту сервер. PHP всегда стоит за http-сервером.
В основе асинхронных систем — события. PHP решает задачу от начала запроса и до конца практически без сохранения состояния (да есть сессии, но убогие).
PHP гораздо более приспособлен для работы со строками и массивами нежели с объектами.
Не всегда PHP стоит за http-сервером. CLI — один из стандартных способов его запуска. Сокеты — в стандартной либе, средства IPC тоже есть. Плохо в PHP с потоками, плюс отсутствие более высокоуровневых стандартных средств для организации хотя бы многопроцессного сервера. Ну и молва, что PHP-приложение в режиме демона или просто сколь-нибудь долгой работы просто обязано течь.
Я вот могу глубоко-приглубоко заблуждаться, но php, лично для меня — это си-подобный серверный ЯП. Соответсвенно он должен решать серверные задачи. Вы сами же говорили двигаться вперед и не оглядываться на «мамонтов», так почему же если стек веб-технологий развился от http до ws — не развивать так же и это в php? Да, php-программистам прийдется познакомиться с событиями, хотя уверен что большинство о событиях знают из js, или фреймворков, в которых они имитируются.
Про строки, массивы vs объекты — вообще не понял.
UFO landed and left these words here
UFO landed and left these words here
PHP 5.2 мало где стоит? Есть свежая статистика по этому поводу? Вроде как раз встречалась обратная инфа, что он один из самых популярных до сих пор. В том, числе и благодаря тому, что Zend сделали новый Guard несовместимый со старыми версиями, ну и конечно куча E_DEPRECATED сообщений.
UFO landed and left these words here
То что он выпилен из популярных репов, ничего не говорит о реальном использовании в инете, на реальных сайтах. Одно дело когда новый сайт делают, то да можно поставить самый свежий софт и под него всё настроить. Другое дело когда у хостеров сотни сайтов, скрипты которых не обновлялись лет 5-7.
На хостингах часто можно переключать версии php. Если у вас vds то вообще проблем нет. Я думаю, что если будет такое обновление хостинги, ранее не поддерживающие возможность переключения версий — сделают ее.
Ставить продукт там где есть 5.2 или ставить себе 5.2 на VDS. Можно сказать новая ниша рынка.
Вы явно сильно преувеличиваете.
PHP Точно умрет, если не перестанут обратные совместимости нарушать. По крайней мере, разрабы продуктов на него забьют и админы.


Абсолютно не согласен. PHP в первую очередь уникален и удобен своей мощью из коробки — тем, что он не просто язык, а уже часть вашей системы. Например для домашних страничек и PHPонеров — это 95% всей системы. Для CMS — 70%. Для сложных приложений — 50% (с расширениями, фреймворками и оптимизаторами). Для highload — это и правда только скриптовый язык, причем один из худших именно из-за обратной совместимости.

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

Какие функции лично у вас вызвали затруднения с депрекейтами (ereg*, split ?).
Кстати, да. Почему-то к PHP очень избирательно относятся. То как скриптовый язык общего назначения его с другими сравнивают, то как фреймворк, смотря с какой позиции его лучше опустить, забывая, что он скорее относится к разряду микрофреймворков.
UFO landed and left these words here
Да не у меня, а у клиентов. Я админ. Клиенты часто просят ставить софт, который не работает под пхп 5.3, а уж под 5.4 и подавно.

5.2 задепрекейчен везде. Такие приходится костыли воротить порой…


Может быть вся проблема в том, что вы админ? Все таки странно пытаться доработать приложения под новые версии ПО системному администратору.

Т.е. представьте, что вы взялись внедрить Windows 98 с поддержкой 64 бит…

И еще раз спрашиваю о каких deprecated вы говорите? А вот вспомнил еще один популярный — передача объектов по ссылке (решается убиранием & в присвоении, split тупо заменяется на explode, ereg* в большинстве случаев на preg).
Чтобы менять split на explode, нужно хоть немного разбираться в PHP. Для клиентов же ситуация выглядит так, всё работало, хостер обновил PHP — на сайте начали выпадать ошибки. Потом у службы поддержки плавятся телефоны от звонков, и они быстро откатывают версию PHP обратно.
Чтобы менять split на explode, нужно хоть немного разбираться в PHP. Для клиентов же ситуация выглядит так, всё работало, хостер обновил PHP — на сайте начали выпадать ошибки. Потом у службы поддержки плавятся телефоны от звонков, и они быстро откатывают версию PHP обратно.


Странные у вас хостеры. Я с такими не сталкивался. От таких лучше бежать без оглядки. А если они Apache на Nginx сменят и вы без htaccess останетесь тоже PHP будет виноват?)
Вполне обычные хостеры, они обычно просто предлагают клиенту разные версии PHP. А в остальном работают по принципу работает — не трогай. Или думаете хостеры будут еще клиентам скрипты править, чтобы они работали?
Вполне обычные хостеры, они обычно просто предлагают клиенту разные версии PHP.


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

тогда ставьте php 5.2 — в чем проблема-то?
UFO landed and left these words here
Есть такая вещь в бизнесе — разделение ответственности. Ваша задача, как специалиста, грамотно объяснить клиенту все плюсы и минусы предлагаемых вариантов — рассказать про безопасность именно данного продукта (как написанного с использованием PHP 5.2).

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

После этого клиент либо откажется, либо уже не сможет в будущем переложить всю ответственность за проблемы на вас.
UFO landed and left these words here
Понимаете, в чем беда… Я довольно часто сам являюсь и админом и клиентом =) Вот такая вот шизофрения, да.


Ну тогда грех жаловаться :-) Сами выбираете не поддерживаемые продукты — сидите, переписывайте, учитесь. Напишите универсальный апдейтер с PHP 5.2 до PHP 5.4 (с заменой функций и т.д.). Денег заработаете :-).
а можно какой-нибудь реальный пример?

Что за мега продукт, который не развивается и не имеет конкурентов?
UFO landed and left these words here
У нас сейчас большая часть проектов на 5.2. Встречается 5.1 и кое-что до сих пор тихонько пашет на 4ке.
Как вообще optimizerplus по стабильности, на живых проектах уже используют? Бояздно пока ставить, слишком много свежих коммитов… =) в том числе:
>> 5 days ago fixed memory leaks [dstogov]
В составе Zend Server уж несколько лет как работает, практически без проблем на production(была парочка segfault но скорее изза кривого железа в hetzner).
я заметил проблемы с симфониевской консолью с версией с одной из февральских версий.
Возможно есть проблемы только в консольных приложения.

А разве в Zend Server используется Zend Optimizer+?
Опкод кэшеры в CLI режиме не работают, им негде хранить промежуточный байткод и кеш, смысл их использовать в CLI пропадает. Включаются только в mod_apache или fastcgi.

Конечно используется, вместе с кучей других полезных компонентов. В последнем ZS (6.0) вообще все красиво, он поставляется в виде платформы для развертывания кластера.
если в консольных приложениях кэширование опкода не работает, тогда чего нужна директива zend_optimizerplus.enable_cli?
Оно работает, в рамках одного процесса, тобишь никакой выгоды не дает. Флаг этот экспериментальный, оставлен для тестеров с CLI приблудами для тестирования в условиях максимально приближенных к боевым.
К слову о MVC фреймворках скомпилированных как extension. Я вот уже 6 месяцев слежу за развитием Phalcon и даже сделал немало приложений на нем.

Аргумент, что Вам необходимо знать С/С++ говорит лишь о некомпетентности. Неужели Вы всегда лезете в core от Zend Framework или Symphony, чтобы что-то поправить? Тогда дайте мне номер телефона Вашего начальника, я сообщу ему, что он зря тратит деньги на Вас. Неужели Вы будете и дальше пихать костыли в следующие релизы? А не забудете ли, что сделали? Для Вас же придумали интерфейсы.

Аргумент, что у меня shared хостинг не катит. Раз приобрели shared, значит Вам и не нужно основное преимущество скомпилированного фреймворка — скорость. (Тут я могу быть в единичных случаях не прав, например мой регистратор по просьбе устанавливает расширения)

Простите, накипело.
Хочу поставить, посмотреть Phalcon, мне очень нравяться его интерфейсы. Но не вижу особого смысла в нем. Производительность по сравнению с популярными фреймворками на синтетических тестах, конечно, воодушевляющия, но часто скорость выполнения PHP далеко не узкое место в приложении, чаще всего — это БД.

А есть тесты, сравнивающие чистый Phalcon с, например, ZF + APC?
Может и есть, но статья об этом была бы интересна ;)
>10000000 слов.

Не критично конечно, но было бы приятнее читать такие числа разбитыми на группы.
Only those users with full accounts are able to leave comments. Log in, please.