LINUX.ORG.RU

Релиз PHP 5.3.0

 


0

0

После четырех релиз кандидатов выпущена первая релизная версия PHP серии 5.3.х :

  • Обновлены bundled версии sqlite и pcre
  • следующие расширения были перемещены в PECL
    • ext/dbase
    • ext/fbsql
    • ext/fdf
    • ext/ncurses
    • ext/mhash (слой BC теперь полностью находится в ext/hash)
    • ext/ming
    • ext/msql
    • ext/sybase (более не поддерживается, используйте вместо него sybase_ct)
  • Несколько изменен синтакс php.ini для удобства и улучшения его читабельности
  • Расширения SPL, PCRE, Reflection теперь включены по умолчанию. Режим FastCGI, к тому же, не может быть отключен
  • Добавлены лямбда-функции и замыкания, оператор «jump label», cинтаксисы NOWDOC, HEREDOC, несколько новых констант
  • Добавлена поддержка пространств имен, добавлена улучшенная обработка исключений (exceptions linking, exceptions in destructors,
  • Улучшена производительность и оптимизировано потребление памяти.
  • Появился сборщик мусора
  • Улучшена поддержка Windows, в том числе и Windows 7
  • Улучшения в расширениях streams, dns api, hash, imap, mbstring, osi8, openssl, pcntl, soap, spl.
  • Новые расширения — enchant (проверка орфографии), fileinfo, intl, mysqlnd, phar (архивы php), sqlite3
  • Многочисленные изменения и улучшения в функциях PHP, исправления ошибок и многое другое

Скачать

Полный список изменений доступен в файле NEWS внутри архива

>>> Подробности

★★★★★

Проверено: boombick ()

Ответ на: комментарий от shaplov

>> в названиях форках нельзя только использовать "PHP", > Чорт...

Предлагаю использовать русские эРэНэР :-)

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от no-dashi

> И вот интересно - куда же вы денете например 60 мегабайт классов в rt.jar?

Я подозреваю, что жаба их не все сразу грузит, а только по необходимости.

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

от этого она не перестает жрать всe 128 Мб :-)

tomcat55 16476 0.5 5.6 356940 117380 ? Sl 21:11 0:13 /usr/bin/jsvc -user tomcat55 -cp /usr/share/java/commons-daemon.jar <blabla> -Xmx32M <blabla> org.apache.catalina.startup.Bootstrap

hizel ★★★★★
()
Ответ на: комментарий от AndreyKl

>а на java? Для начала надо сконфигурировать сервер. Потом понять, что и как ты будешь обрабатывать. И лишь потом можно воспользоваться чем-то вроде jsp. Не каждая птица долетит до середины Днепра, знаете ли.

если уж так рассуждать, то можно скачать apache-tomcat-6.0.20.exe, установить и jsp вполне будет работать. А ещё проще скачать netbeans...

thevery ★★★★
()

Как появится в портах FreeBSD - постараюсь обновить до 5.3. Интересно: будет ли WordPress на нем работать?

exst ★★★★
()
Ответ на: комментарий от thevery

> если уж так рассуждать, то можно скачать apache-tomcat-6.0.20.exe, установить и jsp вполне будет работать. А ещё проще скачать netbeans...

тоже .exe, видимо

bobrik
()
Ответ на: комментарий от Sylvia

  PID TTY      STAT   TIME  MAJFL   TRS   DRS   RSS %MEM COMMAND
...
 6768 ?        RN     0:00      0  6153 59654  7396  0.2 /usr/bin/php-cgi
 6894 ?        SN     2:04      3  6153 59922 25096  0.9 /usr/bin/php-cgi
 7186 ?        SN     2:13      3  6153 60202 27176  1.0 /usr/bin/php-cgi
 7616 ?        SNs    1:02   2525  6153 61642  7480  0.2 /usr/bin/php-cgi
 7638 ?        SN     1:54     12  6153 59426 23920  0.9 /usr/bin/php-cgi
 7883 ?        SN     1:58      1  6153 59378 24564  0.9 /usr/bin/php-cgi
 7921 ?        SN     1:53      5  6153 59442 23276  0.8 /usr/bin/php-cgi
 8178 ?        SNs    0:00      4  6153 54338  2712  0.1 /usr/bin/php-cgi
 8179 ?        SNs    0:00     17  6153 54338  2768  0.1 /usr/bin/php-cgi
 8183 ?        SNs    0:00     14  6153 54338  2756  0.1 /usr/bin/php-cgi
 8189 ?        SNs    0:00     20  6153 54338  2972  0.1 /usr/bin/php-cgi
 8195 ?        SNs    0:00      1  6153 54338  3020  0.1 /usr/bin/php-cgi
 8535 ?        SN     2:20      5  6153 58442 13292  0.5 /usr/bin/php-cgi
 8745 ?        SN     1:59      6  6153 60146 27700  1.0 /usr/bin/php-cgi
 8800 ?        SN     1:50      7  6153 60098 23952  0.9 /usr/bin/php-cgi
 9000 ?        SN     1:51      7  6153 59306 22736  0.8 /usr/bin/php-cgi
 9136 ?        SN     1:53      5  6153 59046 23780  0.9 /usr/bin/php-cgi
 9870 ?        SN     1:49      6  6153 60634 26368  1.0 /usr/bin/php-cgi
 9873 ?        SN     1:52      3  6153 59606 26684  1.0 /usr/bin/php-cgi
 9956 ?        SN     1:58      1  6153 60550 27324  1.0 /usr/bin/php-cgi
 9969 ?        SN     1:55     10  6153 59350 24444  0.9 /usr/bin/php-cgi
 9973 ?        SN     2:07     14  6153 59434 24524  0.9 /usr/bin/php-cgi

...

KRoN73 ★★★★★
()

Интересно, как у него со скоростью и памятью по сравнению с 5.2.9

Интересно, как у него со скоростью и памятью по сравнению с 5.2.9

просто сравнивал вчера php 5.2.9 против python 2.5.4 :)

time php bench.php
5.522u 0.030s 0:05.66 98.0% 2787+3167k

time python bench.py
3.805u 0.000s 0:03.83 99.2% 1078+2778k

победил Python, почти в 1,5 раза (причем он и памяти меньше использовал)

(используется mergesort алгоритм http://en.wikipedia.org/wiki/Mergesort,
исходники есть
php: http://pastebin.ca/1324860
py: http://pastebin.ca/858833)

интересно будет сравнить с php 5.3.0 (ну и с питоном 2.6 и 3.1 раз уж начал...)

zDemoniac
()
Ответ на: комментарий от hizel

Нет, спросили, сколько жрёт PHP - я ответил примером со своей машины :)

KRoN73 ★★★★★
()

>победил Python, почти в 1,5 раза

Очень мало. На числодробилках Питон, особенно с Психо быстрее до десятков раз. На объектах - в разы (c Психо - во многие разы): http://balancer.ru/tech/forum/2008/08/t63003--Proizvoditel~nost~-yazykov.Ob~e...

...

Однако, всё равно практикую PHP ;)

KRoN73 ★★★★★
()

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

d9d9 ★★★★
()
Ответ на: комментарий от KRoN73

> Однако, всё равно практикую PHP ;)

Маладцом =)

exst ★★★★
()
Ответ на: комментарий от sniper21

>это было давно, теперь расшифровывается PHP Hypertext Preprocessor
Угу, герои теперь они типо не быдло -- рекурсивные, это уже мода на рекурсивные названия.. :-((
Но, однакоже все будут помнить их первоначальное название и им уже не смыть этот позор :-))

Bad_ptr ★★★★★
()
Ответ на: комментарий от Bad_ptr

>Угу, герои теперь они типо не быдло -- рекурсивные, это уже мода на рекурсивные названия.. :-((

>Но, однакоже все будут помнить их первоначальное название и им уже не смыть этот позор :-))

tell me moar, безграмотное существо.

portalgun
()
Ответ на: комментарий от Bad_ptr

>Но, однакоже все будут помнить их первоначальное название и им уже не смыть этот позор :-))

Все будут помнить не первоначальное название, а первоначальное, с которым вышли на рынок :)

Изначально PHP не имело однозначной аббревиатуры. И об этом сами разработчики говорили.

"Personal Home Page" родилось заметно позже (чуть ли не в конце 1990-х гг. уже), когда к языку начал расти интерес и вопросы "а как оно расшифровывается" у незаглядывавших в официальный FAQ их задолбали. Тогда и повесили соответствующее название на главной. Ибо так тогда и позиционировались :)

KRoN73 ★★★★★
()
Ответ на: комментарий от d9d9

>Всеравно каждый запрос проходит полную инициализацию скриптов

На общем фоне времени работы - пренебрежимо. Если связка файлов толстая, то и отрабатывает много больше, тех ~0.01сек, что тратятся на загрузку и трансляцию. Если мелкая, то время загрузки и трансляции и того меньше.

...

В любом случае на загруженных сайтах лучше делать генерируемую статику, так как она в разы (иногда - десятки раз) быстрее отдаётся, чем даже примитивнейшие Java-сервлеты :) А вот чем эта статика генерится - уже как раз маловажно. 0.05 сек она будет создаваться или 0.5 - обычно не так критично.

А когда критично, то вопрос сравнения языков даже не встанет. Под свои задачи - свои языки.

KRoN73 ★★★★★
()

ну, как бы, всё стало чуть лучше, хотя то как оно сделано имхо не очень. в замыканиях нужно явно говорить use($то,$сё) тоже мягко говоря смущает и я уверен, что граблей с этим будет вагон.

namespace Some\Declaration\Suxxx; we love windows :) but because we will also work on unix we won't put "C:" in declaration :) wtf is wrong with "::"?

но самое противное что пыха будет жить и пофиг что ибо порог вхождения и кол-во расплодившихся кодеров на ней способствуют.

как язык оно не валом. я перешёл сначала на perl, потом на ruby, сейчас подумываю погрызть python для полноты картины :)

"everything sucks, but something sucks less" (c)

что есть пхп? похапэ есть DSL и как бы не кричали что оно general purpose я никогда не поверю, ибо: тормозно, нет поддержки multithreading/multiprocessing (fork, pthread где? то отож), изначально заточено под web, так что пусть в вебе и крутиться. для некоторых задач оч даже не плох, но не надо равнять его на perl, ruby, python, etc... etc... etc... так же как на C не будут писаться сайты (окромя какого-то embedded'a), так же на php не будут писаться дрова или веб сервера.

naquad
()
Ответ на: комментарий от KRoN73

> На общем фоне времени работы - пренебрежимо. Если связка файлов толстая, то и отрабатывает много больше, тех ~0.01сек, что тратятся на загрузку и трансляцию. Если мелкая, то время загрузки и трансляции и того меньше.

Мне кажется вы недооцениваете возможности, которые даёт предварительная подготовка. Вы можете загнать нужные данные в память не изобретая велосипедов с внешними сервисами кеширования (которые не всегда доступны). В момент запроса можно вообще не обращаться к файловой системе. Апдейтить кеши можно в параллельном потоке. Добавить сюда правильный обработчик темплейтов и динамические страницы могут генерироваться не намного медленнее статики. Да и генерировать всё статикой - это далеко не всегда приемлемо.
Нет, тут даже не сравнимо и никак не пренебрежимо.

> А когда критично, то вопрос сравнения языков даже не встанет.


Критичность относительна. Клиенты любят PHP за его простоту и возможность легко найти кого-то на поддержку проекта и достаточно дешевый хостинг. Зачем усложнять клиентам и себе жизнь?

d9d9 ★★★★
()
Ответ на: комментарий от thevery

>а что, разве пхпшники в большинстве своём разве не под виндой пишут?

Очень удивишься, но под виндой PHP весьма хреново живёт :) В смысле - сам PHP нормально, а вот PHP-проекты под виндой далеко не все нормально пашут. Ибо PHP по многим расширениям сильно на линуксовые либы повязан. От GD и iconv до всяких mp3/sqlite/firebird...

Так что большинство PHP-программистов - линуксоиды :)

KRoN73 ★★★★★
()
Ответ на: комментарий от d9d9

>Мне кажется вы недооцениваете возможности, которые даёт предварительная подготовка.

Ну, я как бы на Java имею опыт работы ;) И в своё время с mod_perl повозился.

>Вы можете загнать нужные данные в память не изобретая велосипедов с внешними сервисами кеширования (которые не всегда доступны)


Ну, тут я memcached-велосипедом обычно пользуюсь ;)

>Да и генерировать всё статикой - это далеко не всегда приемлемо.


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

>Критичность относительна. Клиенты любят PHP за его простоту и возможность легко найти кого-то на поддержку проекта и достаточно дешевый хостинг. Зачем усложнять клиентам и себе жизнь?


Вот поэтому я в web'е сейчас (и уже лет 8 как. Пришёл-то я в web с Перлом) с PHP и работаю. Что клиентом востребовано, с тем и мне не влом повозиться.

Это пока с задачами PHP справляется. Захочет клиент что-то, что этот язык не потянет - придётся клиенту задуматься о хостинге с Питоном или Явой.

KRoN73 ★★★★★
()

Даа, теперь я знаю, что такое ЛОР.

<?php
...
function Petrosyan($count_LOR_analitegs){
   while (true){
      echo "I am Petrosyan! PHP sucks!";
      Petrosyan($count_LOR_analitegs++);
   }
}
...
Petrosyan(0);
?>

valich ★★★
()
Ответ на: комментарий от valich

Fatal error: Maximum function nesting level of 'NNN' reached, aborting!

KRoN73 ★★★★★
()
Ответ на: комментарий от irq

тут больше от скриптов зависит, нежели от PHP

в 5.2.10 неделю назад исправили 1 ошибку безопасности с SEGV при загрузке jpeg с испорченым exif

Sylvia ★★★★★
() автор топика
Ответ на: комментарий от KRoN73

>Очень удивишься, но под виндой PHP весьма хреново живёт :)

я не удивлён, но и под лиуксом многие пхпшные сайты работают так себе, но это зависит от программиста, конечно ;)

>От GD и iconv до всяких mp3/sqlite/firebird...


нуну, и много ли пхп-кодеров постоянно их используют?

к слову, у меня тут знакомый CMS на php пишет (cogear.ru), так вот в комментах у него дофига хомячков с проблемами денвера (дада, про этот велосипед что-то никто и не вспомнил)

thevery ★★★★
()
Ответ на: комментарий от irq

а ну в коде дырки-то латают (и новые добавляют, хаха - PHP 5.2.7), но SQL-инъекции и прочие "XX типичных ошибок php-кодера" никуда не пропадут.

thevery ★★★★
()
Ответ на: комментарий от KRoN73

> Ну, я как бы на Java имею опыт работы ;) И в своё время с mod_perl повозился.

Возиться одно, а довести до уровня искусства свою поделку - другое :)
В данном случае PHP лимитирует своими недоработками и необходимость страдать велосипедизмом несколько напрягает. Вот почему перл может отловить фатальные ошибки и обработать как я хочу, а php нет?

> Почти всегда - приемлемо. Вопрос только в затратах на программирование.


Одного этого достаточно, чтобы задуматься о целесообразности статики. Особенно когда от тебя ждут простоты и гибкости, а не дополнительного геммороя. Да и индексировать тот же форум - сомнительная "приемлимость" :)

> Вот поэтому я в web'е сейчас (и уже лет 8 как. Пришёл-то я в web с Перлом) с PHP и работаю.


Ну чтоже, размеры писек у нас весьма схожи, только тянет их на разное :)

d9d9 ★★★★
()

Поздравляю всех PPH'шников, в том числе и меня самого. Только я уже с месяц как перелез на Python и даже жалеот не собираюсь :)

vitroot ★★
()
Ответ на: комментарий от KRoN73

> Очень удивишься, но под виндой PHP весьма хреново живёт :) В смысле - сам PHP нормально, а вот PHP-проекты под виндой далеко не все нормально пашут. Ибо PHP по многим расширениям сильно на линуксовые либы повязан. От GD и iconv до всяких mp3/sqlite/firebird...

Есть такое. Намучался, прикручивая РНР к IIS6. Решение было проще простого - для PHP запустил еще один сервер. Больше проблем не было =)

exst ★★★★
()
Ответ на: комментарий от dccp

> А замыкания требуют указания захватываемых переменных...

В целом приветствую. Мне всегда замыкания казались стрёмной магией.

yk4ever
()
Ответ на: комментарий от portalgun

> tell me moar, безграмотное существо.

Двачер обвиняет в безграмотности?

sv75 ★★★★★
()
Ответ на: комментарий от irq

>а как у пыхпыха сейчас с безопасностью?

Как, плюс/минус и у любого другого языка.

>или все так же решето?


Оно когда-то было решетом?

KRoN73 ★★★★★
()
Ответ на: комментарий от thevery

>нуну, и много ли пхп-кодеров постоянно их используют?

Много, не много, но под виндой у PHP-шнико постоянно лезет масса проблем, как только сделают шаг влево/шаг вправо за пределы базового функционала.

Поэтому по факту и получается, что на Linux PHP-программеров больше :)

>к слову, у меня тут знакомый CMS на php пишет (cogear.ru), так вот в комментах у него дофига хомячков с проблемами денвера


Так это не потому что среди PHP-программистов больше сидящих на денвере, а потому что у денвера масса проблем :)

>дада, про этот велосипед что-то никто и не вспомнил


А другие решения с PHP под Windows почти и не используются, так что он подразумевается :)

KRoN73 ★★★★★
()
Ответ на: комментарий от thevery

>но SQL-инъекции и прочие "XX типичных ошибок php-кодера"

А какое они отношение к языку имеют? :) Я в своей практике (при командном программировании) самые жёсткие инъекции на Java видел, как раз. А на PHP, вот, увидел было чудовищный код недавно, а влезть через него не смог :) - http://www.linux.org.ru/view-message.jsp?msgid=3777592

...

И, повторюсь, к языку это отношения не имеет. Только к квалификации программиста.

KRoN73 ★★★★★
()
Ответ на: комментарий от d9d9

>Вот почему перл может отловить фатальные ошибки и обработать как я хочу, а php нет?

Если это ошибка синтаксиса - то да, PHP такое не отловит. Но эти ошибки отлавливаются сразу после написания файла, из командной строки. php -l.

А если ошибка периода исполнения - то отлавливается почти всё.

>Одного этого достаточно, чтобы задуматься о целесообразности статики.


А кто-то заставляет писать сразу всё? Можно написать динамику и только когда не станет хватать производительности - включить статику. В любом случае "сложность" эта - когда для написания класса у тебя уйдёт не 15 минут, а 20 минут, скажем ;) Для кого-то - вообще неразличимо. Это просто я такой ленивый :)

>Да и индексировать тот же форум - сомнительная "приемлимость" :)


Кого индексировать? Почему я ничего не индексирую? :)

KRoN73 ★★★★★
()
Ответ на: комментарий от yk4ever

>> А замыкания требуют указания захватываемых переменных...

> В целом приветствую.


Я, пожалуй, тоже. Хотя по любому новый функцонал не буду использовать, пока хостеры сидят массово на 5.1.x и 5.2.x

Я от поддержки PHP4-то и то лишь в прошлом году отказался :)

KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73

>И, повторюсь, к языку это отношения не имеет. Только к квалификации программиста.

ага, и globals со всякими magic_quotes_gpc/stripsplashes/addslashes и htmlspecialchars тоже просто так придумали :D

thevery ★★★★
()
Ответ на: комментарий от thevery

>ага, и globals со всякими

Вопрос глобальных переменных достаточно спорен. И в массе популярных языков (я бы рискнул сказать - в большинстве) глобальные переменные есть :)

>magic_quotes_gpc


А его хоть кто-то в здравом уме включает? Артефактов в PHP немало. Понемногу избавляются. Вот в PHP6 от register_globals совсем откажутся.

>/stripsplashes/addslashes и htmlspecialchars


А это есть вообще в любом нормальном языке :) (естественно, в базовых библиотеках обычно). Или ты на той же Java хочешь совать в SQL-запросы неэкранированные данные? Так я уже и писал про это ранее :)

KRoN73 ★★★★★
()
Ответ на: комментарий от naquad

wtf is wrong with "::" http://us3.php.net/manual/en/language.oop5.static.php

Развели истерику как молоденькие девственницы

В каждом языке есть свои особенности, и сделать нс через :: чревато несовместимостью с 50-60% проектов на предыдущих версиях языка где используются статические методы. Я вот не понимаю зачем писать ху**ю, ведь понятно что языка не знаете.

Abrahuiabra
()
Ответ на: комментарий от KRoN73

>А его хоть кто-то в здравом уме включает? Артефактов в PHP немало. Понемногу избавляются. Вот в PHP6 от register_globals совсем откажутся.

напомнить историю с PHP 5.2.7? ;)

>Или ты на той же Java хочешь совать в SQL-запросы неэкранированные данные?


prepared/ORM, а stripsplashes/addslashes - костыли.

А если выкинуть все legacy-костыли из пыхпыха и заставить проапгрейдиться всех хостеров, обоих своих плюсов(дешёвый хостинг+дешёвые кодеры) пхп лишится :D

thevery ★★★★
()
Ответ на: комментарий от thevery

>prepared/ORM, а stripsplashes/addslashes - костыли.

Это не имеет никакого отношения к языкам.

Повторюсь, зверские SQL-инъекции у меня народ именно в Java допускал.

И, наоборот, за последний год я, наверное, ни разу не пользовался addslashes в PHP. Не смотря на то, что только с БД и работаю. Более того, я прямыми SQL-запросам пользуюсь сейчас лишь несколько раз в год.

Так при чём тут язык?

По-твоему в Python или Java в SQL-запросы вставляются неэкранированные данные? Нет, они и там тоже экранируются, только в случае prepared/ORM - прозрачно для программиста. И в PHP у меня также. Так в чём разница?

KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73

В нормальных языках существуют нормальные dbapi, которые позволяют отделить параметры запроса от его текста. Пыхпых-кодеры вынуждены хардокдить параметры в запрос. (Я уже молчу про вообще отсутствие единого dbapi).

anonymous4
()
Ответ на: комментарий от anonymous4

>В нормальных языках существуют нормальные dbapi, которые позволяют отделить параметры запроса от его текста.

1. Не стоит путать языки и стандартные библиотеки.

2. http://ru.php.net/manual/ru/pdo.prepare.php (и д.р.)

>Пыхпых-кодеры вынуждены хардокдить параметры в запрос.


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

KRoN73 ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.