Доступна (http://php.net/archive/2015.php#id2015-01-11-6) для тестирования первая альфа-версия новой ветки языка программирования PHP 7, отличающейся кардинальной переработкой некоторых подсистем. Релиз запланирован (https://wiki.php.net/todo/php70#timetable) на 12 ноября.
Ключевые улучшения (https://github.com/php/php-src/blob/php-7.0.0alpha1/UPGRADING):
- Существенное увеличение производительности, благодаря применению (http://www.opennet.me/opennews/art.shtml?num=39724) новых методов организации работы с памятью и переходу на новые структуры хранения данных. В некоторых тестах PHP 7 до двух раз быстрее PHP 5.6;
- Целостная поддержка 64-разрядных типов на 64-разрядных системах. В том числе возможность использования сток, размером до 2^31 байт, поддержка 64-разрядных значений integer при работе в Windows, поддержка больших файлов в 64-разрядных сборках.- Возможность обработки через исключения многих ошибок, ранее приводивших к принудительному завершению работы;
- Новый оператор "?? (https://wiki.php.net/rfc/isset_ternary)", позволяющий определить альтернативное значение, в случае если неопределён первичный объект присвоения. Например, для присвоения пустой строки, если не заполнен элемент ассоциативного массива теперь вместо isset($_GET['mykey']) ? $_GET['mykey'] : '' можно указать $_GET['mykey'] ?? "";
- Возможность явного определения (https://wiki.php.net/rfc/scalar_type_hints_v5) скалярных типов int, float, string и bool для аргументов и значений функций (например, "function foo(int $abc): int").
- Режим жесткой проверки типов, включаемый директивой "declare(strict_types=1)", при котором несоответствие типа передаваемого функции или возвращаемого функцией значения будет приводить к ошибке.
- Новый оператор комбинированного сравнения "<a href="https://wiki.php.net/rfc/combined-comparison-operator"&... с реализацией поведения, похожего на strcmp() и version_compare(), но через использование типового синтаксиса операторов сравнения. В частности, новый оператор позволяет не только проверить идентичность операндов, но и оценить какой из них больше другого (0 - равны, 1 - левый больше, -1 - правый больше);
- Поддержка анонимных классов;
- Поддержка группировки определений (https://wiki.php.net/rfc/group_use_declarations) в операторе use (например, use Doctrine\Common\Collections\Expr\{ Comparison, Value, CompositeExpression };);
- Новый метод Closure::call();
- Дополнительный синтакс для встраивания unicode-строк \u{xxxxxx};
- Поддержка задания массивов констант в операторе define();
- Возможность (https://wiki.php.net/rfc/context_sensitive_lexer) использования зарезервированных ключевых слов в новых контекстах (например, можно определить функцию forEach и она не будет пересекаться с оператором foreach);
- Новый синтаксис "yield from выражение" для делегирования (https://wiki.php.net/rfc/generator-delegation) фукциями-генераторами операций в перемещаемые объекты и массивы.
- В дополнение openssl добавлена поддержка TLS-расширения я ALPN (https://en.wikipedia.org/wiki/Application-Layer_Protocol_Neg... (Application-Layer Protocol Negotiation) для согласования протоколов уровня приложений, используемых для обеспечения защищённого соединения. Используется в SPDY и HTTP/2;
- Унификация (https://wiki.php.net/rfc/uniform_variable_syntax) синтаксиса определения переменных и переход к использованию AST (https://wiki.php.net/rfc/abstract_syntax_tree) (Abstract Syntax Tree). Изменение некоторой редко используемой семантики комбинирования переменных (например, $foo->$bar['baz'] теперь интерпретируется как ($foo->$bar)['baz'], а не $foo->{$bar['baz']}). Достаточно большая порция изменений (https://github.com/php/php-src/blob/php-7.0.0alpha1/UPGRADING), нарушающих совместимость;
- Прекращение поддержки старых и не поддерживаемых вызовов SAPI и расширений:
sapi/aolserver, sapi/apache
sapi/apache_hooks,
sapi/apache2filter,
sapi/caudium,
sapi/continuity,
sapi/isapi,
sapi/milter,
sapi/nsapi,
sapi/phttpd,
sapi/pi3web,
sapi/roxen ,
sapi/thttpd,
sapi/tux,
sapi/webjames,
ext/mssql и
ext/sybase_ct;
Дополнительно можно отметить выход (http://php.net/archive/2015.php) корректирующих выпусков языка программирования PHP 5.6.10, 5.5.26 и 5.4.42, в которых устранены (http://php.net/ChangeLog-5.php) восемь уязвимостей и исправлено около десяти ошибок. В функцию mail() добавлена (https://bugs.php.net/bug.php?id=68776) защита от подстановки дополнительных заголовков. В расширении FTP устранено (https://bugs.php.net/bug.php?id=69545) целочисленное переполнение, которое может привести к выполнению кода. В функции escapeshellarg устранена (https://bugs.php.net/bug.php?id=69646) уязвимость позволяющая осуществить подстановку команд операционной системы при экранировании спецсимволов в аргументах к функции system(). Две уязвимости устранены в расширении PCRE (CVE-2015-2325, CVE-2015-2326) и три в Sqlite3 (CVE-2015-3414, CVE-2015-3415, CVE-2015-3416).URL: http://php.net/archive/2015.php#id2015-01-11-6
Новость: http://www.opennet.me/opennews/art.shtml?num=42411
"Кардинальная переработка некоторых подсистем" - это обнадёживает, но посмотрим, с какой частотой будут выходить версии семёрки с исправлением критических уязвимостей.
99% уязвимостей - они в расширениях, в этом смысле ничего не поменялось, только разве что чуточку в лучшую сторону - есть более вменяемые и читабельные макросы для работы с параметрами, где ошибиться намного сложнее. Хотя сделаны они в первую для повышения производительности.А изменения тут в основном в zend engine. Переписали костыль-powered набор регулярок на нормальный Abstract Syntax Tree и оптимизировали потребление памяти, перейдя к более эффективным внутренним структурам. Структуры в LUA подсмотрели частично.
> "Кардинальная переработка некоторых подсистем" - это обнадёживает...вот только в PHP до тех пор пока НЕТ механизма сохранения скриптового состояниия между http-запросами (кроме как то что засунуто в $_SESSION) -- всех этих переработок недостаточно!
при каждом http-запросе -- первым-делом скрипт начинает инициализировать свои многочисленные объекты и структуры... затем быстренько выполняет код , и снова всё "забывает".
а потом опять поновой (в следущем http-запросе) нужно опять всё поновой инициализировать (повторно инклудить хренову тучу PHP-файлов, и повторно заставлять интерпретатор выполнять один и тот же инициализирующий код.. как же это глупо и иррационально!).
такая расточительность -- просто убивает всю производительность, какой-бы она там ни была!
и разумеется phpDaemon не является решением этой проблемы, так как phpDaemon ломает всю обратную совместимость. а без обратной обратной совместимости нафиг этот PHP вообще не нужен.. есть Python\Django и Ruby\Rails, и даже Scala\ЧтоТоТам.
----------
а ведь всего-то что нужно было бы -- это резрешить скрипту сохранять объекты (и в месте с ними их типы) в глобальную область, которая общаяя для выполняемых скриптов.. и в которую можно было бы читать\писать (которая не стирается после каждого http-запроса). пусть даже эта область была бы общая НЕ для ВСЕХ-ВСЕХ-ВСЕХ выполняемых скриптов, а только общая для каждой отдельной нити (Thread) обработчика FastCGI, чтобы не вызывать логических гонок и не мудрить с синхронизацией. и даже эта простая реализация позволила бы увеличить производительность, не нарушая обратную совместимость!
хоспади, даже лень отвечать, какая у тебя каша в том, что у других называется головой
> хоспади, даже лень отвечать, какая у тебя каша в том, что у
> других называется головойПредложение по решению проблемы может и не самое удачное, но проблема описана верно. Потрудись объяснить, где ты видишь кашу.
> Предложение по решению проблемы может и не самое удачноесогласен что решение (предложенное мною) -- говно. да!
просто, я поражаюсь что нет даже его :-)
Промежуточные данные в хранилищах, например [no]SQL базы. Вы хотите из php получить java для разработки локальных приложений?
http://php.net/manual/en/book.pthreads.php
если ты чего-то не знаешь, это не значит, что этого нет. Открой для себя http://php.net/manual/en/book.shmop.php , http://php.net/manual/ru/book.apc.php и храни там свои "состояния":)
Ещё можно сессии в mm хранить. В общем выборов решений - на вкус и цвет, но нет, некоторые упёрлись в классическую плохо пригодную для web модель "всё внутри", и пытаются ей оперировать.
Неужели там всё действительно настолько неоптимально? Мне доводилось читать, что в PHP каждая страница формируется сама по себе, но что даже код самого интерпретатора каждый раз инициализируется заново - такого я даже предположить не мог.
> Неужели там всё действительно настолько неоптимально? Мне доводилось читать, что в PHP
> каждая страница формируется сама по себе, но что даже код самого
> интерпретатора каждый раз инициализируется заново - такого я даже предположить не
> мог.И при этом всём он ни фига не медленнее руби с питоном. Сюрпрайз?
> И при этом всём он ни фига не медленнее руби с питономТы не понял сути проблемы. Большинству сайтов эта фича не нужна, оттого и не медленнее.
В случае если по каким-то причинам восстановление состояния занимает кучу времени то руби с питоном выиграют потому что там с этим проблем нет.
Это ты не понял сути проблемы. В PHP совершенно другая модель разработки, если тебе между запросами обязательно, вот ну прямо вешалки, надо хранить километры _внутреннего_ (!) состояния процесса - тебе мимо. Куда-то в сторону жабы или дотнета. Ну или для совсем примитива - nodejs.Для хранения того, что желательно хранить - есть СУБД, memcached, да APCU хотя бы. А если очень хочется что-то вот так мудрёно посчитать с большим стейтом (какую-то конкретику) - можно заюзать gearman/zeromq/rabbitmq/..., и разделить приложение на нестейтовый фронтенд и фоновую стейтовую логику, да ещё и распараллелить последнюю при этом. Ни капли не потеряв гибкости и плюшек языка. Решения есть, другое дело, что не надо совать одну и ту же "единственно расово верную" парадигму затычкой в каждую бочку.
> Это ты не понял сути проблемы. В PHP совершенно другая модель разработки, если тебе между запросами обязательно, вот ну прямо вешалки, надо хранить километры _внутреннего_ (!) состояния процесса - тебе мимо. Куда-то в сторону жабы или дотнета. Ну или для совсем примитива - nodejs.
> Для хранения того, что желательно хранить - есть СУБД, memcached, да APCU хотя бы. А если очень хочется что-то вот так мудрёно посчитать с большим стейтом (какую-то конкретику) - можно заюзать gearman/zeromq/rabbitmq/..., и разделить приложение на нестейтовый фронтенд и фоновую стейтовую логику, да ещё и распараллелить последнюю при этом. Ни капли не потеряв гибкости и плюшек языка. Решения есть, другое дело, что не надо совать одну и ту же "единственно расово верную" парадигму затычкой в каждую бочку.Это классическое CGI-поведение. Не нужно выдавать неполноценность PHP за особенность.
В Perl без лишних телодвижении можно:
- как сохранять состояние локально (кэшировать) и обеспечивать доступ к кэшу из любого процесса (IPC::SharedCache); собственно, у меня так и сделано кэширование сессии для того чтобы получить инфу без обращения к базе, записью в базу занят совершенно другой процесс работа которого не тормозит обработку запросов
- так и выполнять полную фазу с нуля создания и инициализации объектов, обработки данных и их освобождения.Причем, эти и другие схемы элементарно реализуется как в standalone-приложениях, так и под apache/modperl. Все работает очень быстро если конечно не вы не пишете CGI-скрипты. Используя Inline:: модули и XS вы можете забрать даже свои "5% производительности".
Поверьте мне, я знаю о чем пишу. Не зря я так тщательно и долго искал более совершенный инструмент для работы.
> В Perl без лишних телодвижении можно:С перлом только одно: код там прочитать чужой без лишних телодвижений можно, не обладая чёрным поясом и докторской по оному?
> С перлом только одно: код там прочитать чужой без лишних телодвижений можно, не обладая чёрным поясом и докторской по оному?Можно конеч. Я читаю, дорабатываю как свои код, так и занимаюсь модулями из CPAN.
Я вам больше скажу, когда я был мальнким, я английский не понимал совсем. Совсем-совсем не понимал. Сейчас же я не обладая черным поясом и докторской, я не только понимаю английский.PS: Кроме Perl и PHP я владею всякими Си,С++,JavaScript, Java, C#, VB и другими языками, но предпочитаю Perl.
>> В Perl без лишних телодвижении можно:
> С перлом только одно: код там прочитать чужой без лишних телодвижений можно,
> не обладая чёрным поясом и докторской по оному?Да конечно можно, вопрос нечитаемого кода - он не в языке, а в быдлокодерах, которые этот код писали.
Написать ужос и на яве легко, и на питоне. Ну спецсимволов там будет поменьше, но что с того - быдлокод он и в африке быдлкод.
Фуфло это всё. Я сначала когда на перле писать начинал, тоже так думал.В пыхе идея в том, что вместо того, чтобы грузить в память сразу всё своё говнище - приложение и 100500 зависимостей, и держать их там до скончания веков + получать утечки памяти, ты заюзаешь autoload и на каждый запрос у тебя будет загружаться только десяток классов - именно те, которые нужны, а не все подряд. При этом они по факту ещё и кэшируется в компилированном виде apc/opcache'ем и загрузка их занимает минимальное время. А вместо 100500 зависимостей с CPAN'а ты заюзаешь два с половиной нативных модуля, потому что всё остальное и так встроено в язык.
А IPC::SharedCache и механизм работы с сессиями твой фуфло потому, что на два сервера он уже не масштабируется.
> Фуфло это всё. Я сначала когда на перле писать начинал, тоже так думал.Я так понял что ты не осилил в итоге? Ну а я - осилил :-). Теперь я копаю глубже - в XS, компилятор Perl и исходники интерпретатора.
> В пыхе идея в том, что вместо того, чтобы грузить в память сразу всё своё гоwнище - приложение и 100500 зависимостей, и держать их там до скончания веков + получать утечки памяти, ты заюзаешь autoload и на каждый запрос у тебя будет загружаться только десяток классов - именно те, которые нужны, а не все подряд. При этом они по факту ещё и кэшируется в компилированном виде apc/opcache'ем и загрузка их занимает минимальное время. А вместо 100500 зависимостей с CPAN'а ты заюзаешь два с половиной нативных модуля, потому что всё остальное и так встроено в язык.То есть в пыхе все все гоwнище сразу в памяти еще до старта? Судя по тому сколько ошибок закрывается постоянно в PHP - гоwнища там не слабо и оно похоже отборное и ядреное :-).
Чтобы не грузить 100500 зависимостей из CPAN я тебе советую не включать модуль Dist::Zilla в свой проект :-), с остальным вроде бы проблем нет.
Ты никога не слышал про модули AutoLoader и SelfLoader поставляемые с ядром Perl? А про то что в Perl код компилируется?
> А IPC::SharedCache и механизм работы с сессиями твой фуфло потому, что на два сервера он уже не масштабируется.Кто тебе насвистел такое? Или ты просто ниасилил? Ну так я осилил. Ты не умеешь горизонтальное маштабирование? Я бы мог научить тебя горизонтально масштабировать приложения, но ты же пхп-шник :(.
Изыди троллятина онанимусная. Осилил, не осилил, по существу бы лучше что-то сказал
Сказал же что я осилил горизонтально масштабирование с IPC::SharedCache.
Умница
P.S: Никто тебе, кстати, не мешает написать на пыхе свой HTTP сервер - есть даже асинхронные движки типа как node.js - например http://daemon.ioПросто это для обычных сайтиков нафиг не нужно и поэтому в общем-то не принято.
Вы предлагаете писать на PHP ? Не уважаете других - уважайте хотя бы себя.
И как же вы такие вот negotiation'ы будете уникально идентифицировать, а? По сессионному ID? По IP? Я вашим таким ПХП память съем за несколько минут простейшим досом/ддосом, создавая уникальные сессии.
отвечу.PHP-fpm постоянно крутит заданное количество рабочих процессов PHP, которые с версии 5.5 имеют встроенный zend cache. Zend cache сохраняет готовый байткод для исполнения, никакие файлы не инклудятся после первого запуска.
Как код напишешь так и будет- никакой халявы тут не бывает.
Для сохранения состояний есть специализированые средства от отдельного демона c zeroMQ и redis до mongoDB и других баз данных.Да всё это тоже есть в python, perl и ruby. PHP быстрее изначально и у него очень близкий синтаксис к C.
> PHP быстрее изначально и у него очень близкий синтаксис к C.Вы либо СИ в глаза не видели, либо пхп, если разглядели близкий синтаксис, но скорее всего вы просто невежда который знает поверхностно 1 или 2 яп но мнит себя мега специалистом.
> PHP-fpm постоянно крутит заданное количество рабочих процессов PHP, которые с версии 5.5 имеют встроенный zend cache. Zend cache сохраняет готовый байткод для исполнения, никакие файлы не инклудятся после первого запуска.Зафигачили еще один костыл, в виде кэширования опкодов, но суть от этого не изменилась, он также инклудит файлы только теперь их не нужно парсиь и переводить в опкоды и они находятся в кэше, посмотрите как сделано у нормальных серверных приложений в нормальных ЯП. НОрмальные ЯП это (python,ruby, java, golang)
> Для сохранения состояний есть специализированые средства от отдельного демона c zeroMQ и redis до mongoDB и других баз данных.Ну естественно кто не может юзать шаред мемоми тот использует другие решения.
>> PHP быстрее изначально и у него очень близкий синтаксис к C.
> Вы либо СИ в глаза не видели, либо пхп, если разглядели близкий
> синтаксис, но скорее всего вы просто невежда который знает поверхностно 1
> или 2 яп но мнит себя мега специалистом.Абсолютно близкий к ц++. Мне тут статья попалась с примерами на пыхе, которого я до того в глаза не видел. Все оказалось совершенно понятно. А вот чем вы смотрите я не знаю.
Стоит различать стадию парсинга исходников и превращения их в байткод от стадии выполнения. Проблемы пыха именно на стадии выполнения. Инициализация объектов идет, сюрприз, на стадии выполнения. Так что php-fpm в этом волпросе ничем не помогает. Для тех, кто не ел ничего слаще морковки, расскажу как работает fcgi во всех вменяемых языках.
1. Запускается главный скрипт, который инклудит все основные модули. Это php-fpm способен решить.
2. Выполняется инициализация всех основных объектов. В больших проектах это очень затратная часть, может доходить до секунд. Пых в пролете.
3. Запускается цикл обработки запросов. И каждый запрос начинает обрабатываться в уже полностью готовом окружении, а не повторяет заново стадию инициализации. Опционально имеется крайне дешевый IPC, вместо использования БД и прочих костылей.
Не могу не пройти мимо этого бреда
>PHP быстрее изначально и у него очень близкий синтаксис к C.Чувак, синтаксис к скорости не имеет практически никакого отношения. Особенно, если мы говорим о fcgi(включая убогий php-fpm), где парсинг делается ровно один раз. Скорость конкретных реализаций ЯП на некоторых задачах можно посмотреть на http://benchmarksgame.alioth.debian.org/
Казалось бы что проще. Ну планируешь проект, который в пыхе "инициализируется несколько секунд", ну не используй и все.
Найди десяток сишников посади их года два писать проект (они посреди дня еще трепаться будут здесь и на ЛОРе), вкрячь кучу бабла и пролети мимо прибыли, для надежности повтори 10 раз.
У тебя подростковое черно-белое мышление? Кроме php и C других ЯП нет?
> У тебя подростковое черно-белое мышление? Кроме php и C других ЯП нет?а я знаю! жаба исчо!
И при каждом падении замечательно падает всё окружение со всеми дофигища исполняемыми запросами. А при "нелетальном" повреждении памяти... ээээ... кхм...
Это рассуждение в стиле "взрыв снаряда в стволе гаубицы куда смертоносней для ее расчета, чем треснувшее древко стрелы у лучника, давайте будем использовать лук и стрелы, вместо гаубиц".
Ну и с чисто технической стороны речь шла про классический fcgi, который выполняет запросы последовательно. Рассказывать пыхарям про конечные автоматы и параллельное выполнение запросов одной копией скрипта уже было бы избиением младенцев. Пусть хоть обычный fcgi освоят.
Конечные автоматы говоришь? А кто тебе мешает приложение разделить на стейтфул бэк и стейтлесс фронт, и связать через какой-нибудь минималистичный MQ? При этом плюшкой сверху получишь возможность юзать много бэков, если нужно. Яйца?Вот ещё раз убеждаюсь, что пишут подобное только люди с закостеневшими мозгами... которые не понимают, что всё это спокойно реализуется на любом современном языке, но не всегда любимая ими парадигма - правильное решение.
Пример: у меня есть небольшое приложение, которое хитрый фронт к астериску и телефонам. Есть определённый стейтовый бэк, который непрерывно читает состояния астериска с AMI, в т.ч. с непрерывно текущих эвентов (на фронте это делать - слишком овердофига коннектов к AMI и полных чтений состояния, а эвенты бесполезны), и есть фронт, который очень шустро забирает у бэка эти данные по запросу. В итоге фронт не ждёт чтения состояния, а бэк имеет возможность работать непрерывно. И никакого особого усложнения кода не произошло, скорее наоборот. Падение бэка не убьёт фронт, падение фронта убьёт только один запрос. Профит.
Тебе осталось найти такое решение в php. Теоретически конечно можно написать толстый демон(кстати, кроме как посредством внешних утилит типа nohup это сейчас вообще возможно? Как там у пыха с возможностью сделать fork и сменить sid?) на php, к которому будут обращаться тонкие php клиенты, работающие в стиле cgi. Вот только пока наблюдать такого зверя не приходилось. А вот обычную промежуточную стадию между cgi и fcgi с кучей костылей, например запуску по cron, вижу сплошь и рядом.
Опять же - ищем проблемы там, где их нет. Чем nohup не угодил - я не знаю, но для любителей есть и следующее.---
# child gets instantiated, note that child must NOT use any of the parent resources
$pid = pcntl_fork();
if ($pid < 0) return false; # failed
if ($pid != 0) return true; # succeeded# ignore child signals and detach from controlling pty
pcntl_signal(SIGCHLD, SIG_IGN);
posix_setsid();# fork second time
$pid = pcntl_fork();
if ($pid != 0) exit; # failed to fork second time or master# second level slave here, detached from the master pty, we still detach it again to be safe
posix_setsid();
---
> Конечные автоматы говоришь? А кто тебе мешает приложение разделить на стейтфул бэк и стейтлесс фронт, и связать через какой-нибудь минималистичный MQ? При этом плюшкой сверху получишь возможность юзать много бэков, если нужно. Яйца?А причем тут архитектура приложений и кривой пхп? Вы мне по факту предлагаете использовать 2 ЯП, но зачем мне если я могу юзать один нормальный и не гимороиться с MQ инфраструктуру еще поднять нужно и обслуживать.
> Вот ещё раз убеждаюсь, что пишут подобное только люди с закостеневшими мозгами... которые не понимают, что всё это спокойно реализуется на любом современном языке, но не всегда любимая ими парадигма - правильное решение.Вот еще раз убеждаюсь что мыши любят жрать кактус, а не использовать нормально реализованный ЯП.
> Вы мне по факту предлагаете использовать 2 ЯП1. Какие два ЯП? Где?
2. ZeroMQ? Или Gearman? Инфраструктуру? Ну я даже не знаю.
3. Конечно же, один процесс, который при падении уронит все запросы, а при повреждении постоянных структур - ёкнет сразу кучу пользовательских данных, с шансом отписать результат в persistent storage - это куда лучше.Нет, общаться с людьми с костями в мозге - это тяжко... Всё, завязываю.
Аналогично
лолка, что тебе мешает иметь демона в котором все нужные объекты уже инициализированы и обращаться к нему из быстро загружаемых клиентов?>>Чувак, синтаксис к скорости не имеет практически никакого отношения.
синтаксис отностися к удобству восприятия, это как и высокая скорость выполнения является преимуществом PHP перед другими языками.
>>Скорость конкретных реализаций ЯП на некоторых задачах можно посмотреть на http://benchmarksgame.alioth.debian.org/
вот и посмотри, PHP из скриптовых пока уступает только LuaJIT и Javascript на V8, с версии 7 отставание значительно сократится.
> вот и посмотри, PHP из скриптовых пока уступает только LuaJIT и Javascript на V8, с версии 7 отставание значительно сократится.Не смешнее меня ладно, уже не однократно писалось что тесты на данном сайте вообще не объективны, я лично оптимизировал пару тестов и они начинали работать в 1.5-2 раза быстрее.
Что? А Dart на 6-м месте что не скриптовый?
разве он очень популярен?
> вот только в PHP до тех пор пока НЕТ механизма сохранения скриптового
> состояниия между http-запросами (кроме как то что засунуто в $_SESSION) --Просто там совершенно другая модель работы, которую вы не осознаёте.
> вот только в PHP до тех пор пока НЕТ механизма сохранения скриптового
> состояниия между http-запросамиmemcached для данных + opcache для скриптов -> все что нужно будет жить между запросами
"Кардинальная переработка некоторых подсистем" - это значит, что все те подсистемы, которые за много лет были более-менее очищены от багов, теперь придётся очищать по новой
И когда уже declare(strict_types=1) будет по умолчанию и неотключаемой?
Вряд ли скоро. И хорошо что так.
Одни вон (не буду тыкать пальцем) доигрались с обратной совместимостью
Думаю, никогда - будет так же, как в JavaScript с 'use strict': BC поддерживается, но писать без стрикта - моветон и ататат.В JS мне совсем не мешает - поставил галочку в IDE, чтобы автоматически вставляло use strict, и все дела. Можно и без IDE - те же vim и emacs с задачей вставить строку при создании файла определенного типа справятся легко.
С перлом не попутали?
http://www.w3schools.com/js/js_strict.asp
https://developer.mozilla.org/en/docs/Web/JavaScript/Referen...
Не попутал - я, в отличие от вас, имею опыт разработки на JavaScript.(Интересно, какие идиоты плюсуют такие высказывания).
глупости. строгая типизация не приживется, а будет использоваться только в исключительных случаях.
Зависит от того, в каком обществе.В среде программистов лапшой на вордпрессах - вряд ли.
А в комьюнити вокруг symfony2 - вполне.
Потенциально скоро дорастут до Java.
А оттуда и до плюсов недалеко...
> Потенциально скоро дорастут до Java.пхп сейчас роет себе яму, а с релизом постепенно начнут пхп прикапывать.
Эта яма называется рыночной нишей: веб и клиент-серверные приложения. У Java проблемы не архитектурные, а тезис был об этом (ОО парадигмы очень похожие сейчас).
На самом деле PHP за пределы веб выбрался уже давно, просто эти приложения слегка не на виду.
Кроме мертворожденного php-gtk не могу припомнить...
> use Doctrine\Common\Collections\Expr\{ Comparison, Value, CompositeExpression };);
> ??
> <=>Сначала мы значит от перла уходим, типа нечитаемо, немодно, надоел и вообще. А сейчас - тихой сапой оттуда тащим фичи десятилетней давности. Окей.
Вот только сделают как обычно, через задницу.
Пусть перл тоже стащить вещи десятилетней давности типа нормального ООП и сигнатур функций и я переметнусь обратно.
ооп не нужно
там есть пакеты, кложуры
используй функциональный подход и композицию вместо наследования - будь мужиком!
> сигнатур
> функций и я переметнусь обратно.ненене
сигнатуры ограничивают и загоняют тебя в рамки при реализации функцийбез сигнатур - возможности в реализации ограничены только твоим разумом
В этом вся проблема и есть.
Когда надо принудительно ограничить возможности (инкапсулировать что-то, сделать строгий вызов функций, ограничить типы) в перле надо дополнительно измудряться. И каждый измудряется по своему. На определенном уровне все эти "костыли с гибкостью" даже если и требуются то решаются узким кругом людей в ограниченном месте с помощью еще более низкоуровневых плагинов например на С.
А пых сознательно идет на ужесточение ограничений.
Один из двух основных принципов Perl это "есть много способов содрать с кошки шкуру". Именно за это он любим. Вот только вменяемые перловики знают, что в команде всегда можно ввести _наиболее удобный большинству_ набор ограничений на способы снятия шкуры. После чего вместо разброда и шатания получаем не менее однозначный чем у питона вариант написания и оформления кода, но при этом он не навязан каким-то Гвидо, а выбран самой командой.
> Один из двух основных принципов Perl это "есть много способов содрать с
> кошки шкуру".Это что-то из официальной документации?
Вы - тролль.
Не нужно ООП. Вы еще тут начните говорить чтобы в Си классический ООП ввели. Нету в этих языка ООП и не нужно, это ООП-нотация которая позволяет реализовать если оно требуется. Вы наверное не знаете но техники наследования, полиморфизма и инкапсуляции реализуются и в Си довольно легко, а в Perl - и подавно.
Не нужно трактора. Лопата есть. Вы наверное не знаете, что вдвоём копается лучше, а всей семьёй до пятого колена - и подавно.
> Не нужно трактора. Лопата есть. Вы наверное не знаете, что вдвоём копается лучше, а всей семьёй до пятого колена - и подавно.Вы - тролль.
Ды ладно :)
Критерий "нормальности" - фстудию!На данный момент есть: штатный, через blessed хэши, и куча других реализаций: Moose, Mouse, Mojo. Есть даже inside-out.
Сигнатуры добавили в 5.20.
>> use Doctrine\Common\Collections\Expr\{ Comparison, Value, CompositeExpression };);
>> ??
>> <=>
> Сначала мы значит от перла уходим, типа нечитаемо, немодно, надоел и вообще.
> А сейчас - тихой сапой оттуда тащим фичи десятилетней давности. Окей.
> Вот только сделают как обычно, через задницу.Да, +100, неймспейсы эти в пыхе - это по-моему худшая из возможных реализаций. Даже синтаксис неймспейсов самый уродский из всех языков...
А я то думал, они 7 версией удивят, а оказалось что это просто перестановка мебели.
ожидали увидеть яву?
Нехай веселятся. GO их скоро сожрет с потрохами.
"В некоторых тестах PHP 7 до двух раз быстрее PHP 5.6;"Какой тонкий маркетинг! А ведь можно и так прочитать:
"В похапэхе 5.6 некоторые функции были до того уродски спроектированы, что работали в 2 раза медленнее того, как можно было сделать подумавши".Вообще само существование похапэхи при наличии УЖЕ НАПИСАНОГО Перла - непонятный маразм. Синтаксис - видно откуда пёрли, так зачем это писали вообще? Поверхностный буржуйский ум готов применять любую парашу, лишь бы писать поменьше, а думать о перспективах - пусть яйцеголовые этим занимаются!
Читал новость: http://www.opennet.me/opennews/art.shtml?num=42387 ?PHP изначально назывался "Perl for Home Pages" и представлял из себя набор CGI Perl-скриптов. Не могу сказать почему функционал который был в CGI-скриптах не был представлен в виде Perl-модулей, но склоняюсь к мысли что это от неосиляторства. Ну а дальше CGI-скрипты тупо "толстели" без какой-либо вменяемой концепции. Практика показала что многим и такое вполне сгодилось в пищу..
~70-80+% веб-сайтов в мире на протяжении уже больше пяти лет, да ещё с постоянным ростом и суровый крупняк типа фейсбука и вконтакта включая - это что угодно, но точно не неосиляторство.
Вспоминая про большинство и 95% населения:"Если вы заметили, что вы на стороне большинства, это верный признак того, что пора меняться."
Марк Твен
> "Если вы заметили, что вы на стороне большинства, это верный признак того,
> что пора меняться."Ещё не ходите на руках по улицам, и не ездите на бочке на работу? А пора бы меняться.
Очень слабо (как раз соответствует уровню пхп-шника).
Оо да у вас хватает невежества спорить с Марком Твеном.
> Оо да у вас хватает невежества спорить с Марком Твеном.Да нет, это у вас хватает наглости пользоваться чужими выражениями для достижения собственных мерзеньких целей.
А что пхп разработчики уже начали получать нормальную зарплату? или как обычно вместо одного разработчика на ruby,python нанимают двух на пхп за те же деньги?
> фейсбука и вконтакта включая <Которым в итоге пришлось в итоге выкинуть стандартную реализацию (Zend PHP) и пилить свои. Не очень удачный пример.
> Которым в итоге пришлось в итоге выкинуть стандартную реализацию (Zend PHP) и пилить свои. Не очень удачный пример.Отчасти тоже бестолково сделали, т.к. можно было решить задачу более элегантно используя уже существующие решения. Хотя там корпорация, а они всегда ходят засадить себе и всем вокруг "вендор-лок".
Ну что, запилили. Молодцы. Кроме фэйсбука на HHVM как минимум википедия теперь крутится. И что в этом плохого? Будем ставить в упрёк Питону, что они до сих пор не реализовали JIT в референсном CPhyton и народу пришлось пилить для этого PyPy? Логика развития современных скриптовых языков, однако. А если в седьмом пыхе люди правда добились сравнимого с "хипхопом" быстродействия, но без всякого джита, то на это даже становится интересно посмотреть.
PHP - пожалуй самый худший предметно-ориентированный язык который я видел.
Perl же
PHP - это давно уже не Perl сразу с момента как как закончилось использование CGI-скриптов.
Perl создавался для обработки текста, но так как любые данные по сути являются текстом, то вполне логично что Perl оказался пригодным и всюду. Поэтому и интерпретатор что "безтиповые" данные обрабатываются через интерпретацию согласно написанному сценарию.
> PHP - это давно уже не Perl сразу с момента как как
> закончилось использование CGI-скриптов.
> Perl создавался для обработки текста, но так как любые данные по сути
> являются текстом, то вполне логично что Perl оказался пригодным и всюду.
> Поэтому и интерпретатор что "безтиповые" данные обрабатываются через интерпретацию согласно
> написанному сценарию.и потому Perl - самый худший предметно-ориентированный язык (и это правда(с)васильева)
> и потому Perl - самый худший предметно-ориентированный язык (и это правда(с)васильева)Это не так, Perl - один из мощнейших языков программирования общего назначения. Только многие его не смогли осилить из-за недостатка IQ.
Интересно, что же стало с PHP6 ?
в армию забрали
Авторы испугались, что php six похоже на php sux.
PHP 6 была попыткой перевести все на юникод, от чего позже отказались,
тем не менее книжки и статьи были написаны, вот чтобы народ не смущать 6-кой, от которой отказались, ее пропустили.