LINUX.ORG.RU

Вышел PHP 5.4.0

 ,


0

0

Разработчики PHP рады сообщить о релизе популярного языка программирования под номером 5.4.0. В релиз вошли следующие изменения:

  • Новые синтаксические конструкции:
    • Traits - иначе говоря - миксины, то есть, наборы методов, которые можно использовать в нескольких классах
    • краткая запись массивов - $a = [1, 2, 3, 4]; или $a = ['one' => 1, 'two' => 2, 'three' => 3, 'four' => 4];
    • <?= доступен всегда, независимо от значения опции short_open_tag
    • Числа в двоичном формате теперь можно записывать в формате 0b001001101
    • остальные изменения
  • Улучшена производительность и уменьшено потребление ОЗУ
  • Улучшены сообщения об ошибках и предупреждения
  • Поддержка многобайтовых кодировок теперь присутствует во всех сборках и может быть включена и выключена в настройках.
  • В режиме CLI появился встроенный вебсервер - для удобства разработки

Обратно-несовместимые изменения:

  • Убраны register globals, magic quotes и safe mode
  • Убрана конструкция break/continue $var
  • Убрана опция allow-call-time-pass-reference

Версия 5.4.0 будет последней, в которой будут официально поддерживаться ОС Windows XP и Windows 2003.

Руководство по апгрейду с версии 5.3 доступно здесь.

Полный чейнджлог можно прочитать здесь.

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

★★★★★

Проверено: JB ()
Последнее исправление: provaton (всего исправлений: 7)
Ответ на: комментарий от helios

Только что дошло, что за бред оно считает:
0x0+10 == 0x10 + 10 == 16 + 10

по аналогии:
0x0+100 == 0x100 + 100 == 256 + 100
0x0+1000 == 0x1000 + 1000 == 4096 + 1000
0x0+9 == 0x9 + 9

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

0x0+10 == 0x10 + 10 == 16 + 10

Нет, это то я понял, но вот почему?

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

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

goingUp ★★★★★
()
Ответ на: комментарий от helios
php -r 'echo 0x0+10;' # 26
php -r 'echo 0x0 + 10;' # 10

Это такой баг. Буквально на днях исправили кстати

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

«Подавляющее множество людей» - звучит «угловато».

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

Это всё замечательно. Я даже верю в IP по голубиной почте. Но в реальном мире правит рынок. Людям нравится, когда красиво свёрстано, когда логотипы и прочие радости жизни.

Ещё раз: «людям» - это Вашим соседям? :) Мои заказчики практически единодушно просят оставлять их подписчикам выбор вида получаемых e-mail: HTML или «plain text». Это, наверное, следствие того, что они Perl «не осилили»? ;)

По-моему, Вы слишком уж категоричны в своих попытках масимализма...

Ну как «зачем»? В базе лежат уже гарантированно _чистые_ данные, готовые к употреблению даже самой же базой.

«Чистые» от чего?

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

Аналогично. Вот только не всякие данные нужно, и, главное, можно, экранировать. Или - всякие? :)

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

Python/Ruby по производительности сливают нормальным ЯП конкретно. Поэтому лучше сразу на Java делайте средний проект, на вырост. Потом большого геморроя избежите, по переписыванию с сабжей на приличный ЯП.

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

Есть три вида платформ:
1. интерпритатор
2. виртуальная машина
3. нативный код

Есть три области:
а. веб - нужна прослойка между юзером и БД, скорость не критична, скорость разработки и выкатывания новых фич критична, постоянно что то меняется, добавляется
б. вычисления в реальном секторе(банковский, медицина и т.д.) - скорость не сильно критична, надежность критична, скорость разработки не сильно, сначала много проектируется, после сдачи почти не трогается
в. просто вычисления, десктоп приложения - скорость очень критична, надежность не критична (бекапы рулят)

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

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

Отсюда следует что:
1. Java-машина и python-интерпритатор не конкуренты
2. Java-машина конкурирует на одном поле с .Net-машиной
3. для веба отлично подходят интерпритаторы, и на этом поле конкурируют интерпритаторы Perl,PHP,Ruby,Python

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

и на этом поле конкурируют интерпритаторы V8, PHP, Ruby, Python

fixed

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

Perl мертв.

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

Perl мертв для веба, скриптики писать никто не отменял

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

Надо рассказать фейсбуку и прочим, что их письма не доходят :(

Не надо. Пусть так и продолжают не доходить. А то ещё новые правила придумывать для этого мусора...

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

Говноеды - это учать похапастов, увы. Неосиляторы Перла, они всю жизнь кодят

А осиляторы перла, полагаю, слегка «покодив», пересаживаются сразу на яхту с девочками/ламборджини/вертолет?

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

Это не пхп, где можно сложить файлики по пхп в папочку и радоваться.

А это, имхо, минус.

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

mantar> интерпритатор
mantar> python-интерпритатор
umren> интерпритаторы

Вы твинк или близнецы-братья?

...

Кстати, где вы нашли Python-интерпретатор? Боюсь, что вы пользуетесь терминами, значение которых не понимаете.

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

3. для веба отлично подходят интерпритаторы, и на этом поле конкурируют интерпритаторы Perl,PHP,Ruby,Python

Вполне вероятно что все они конкурируют, в чем я, лично, сильно сомневаюсь. Но что с чем конкурирует? В практически наиболее востребованной области еCommerce? И какой же там расклад? Какие решения на ruby/perl/python по потребительским качествам можно смело противопоставить Magento/PrestaShop/ZenCart ?

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

php -r 'echo 0x0+10;' # 26
php -r 'echo 0x0 + 10;' # 10

это баг, если неставить пробел, то число которое ты прибавляешь становится самим хексом 0x10 + 10

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

для веба отлично подходят интерпритаторы, и на этом поле конкурируют интерпритаторы Perl,PHP,Ruby,Python

Да, конечно. Если тебя устраивает производительность на уровне 10 ответов в секунду. Или любишь дикие танцы с бубном, чтобы эту производительность поднять, то да - подходят.
Сначала они экономят время, потом его забирают.

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

Вполне вероятно что все они конкурируют, в чем я, лично, сильно сомневаюсь.

Perl это прошлое. PHP это настоящее. Rubu/Python это будущее.
Так что ваша правда, не конкурируют. Python будет конкурировать с Ruby.

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

Python будет конкурировать с Ruby.

since 2004? если говорить о вебе =)

сомневаюсь, что это можно назвать будущим

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

голый ответ на питоне

Голый ответ на C под 10к и че? Много видел приложений, отдающих голый ответ?
Вот только с каждым новым запросом ему не нужно будет делать дурну^W парсить одни и те же файлы.
Не говоря уже про возможность кешировать что-то в памяти в пределах инстанса.

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

парсить одни и те же файлы

это что за python такой?

Не говоря уже про возможность кешировать что-то в памяти в пределах инстанса.

и это тоже python может

а ответы пусть кэш кэширует

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

интерпритаторы Perl

Внезапно Perl исполняет компилированный байт-код, и отлично поддерживает fast-cgi, убирая необходимость его повторной компиляции при обращениях.

om-nom-nimouse ★★
()
Ответ на: комментарий от d9d9

Голый ответ на C под 10к и че?

% ab -n 1000 127.0.0.1:4567/ 2>/dev/null| grep 'per second'
Requests per second:    2748.50 [#/sec] (mean)

Руби, синатра, отдающая статическую строку. Не 10к, но для тормозного языка неплохо, не так ли?

Много видел приложений, отдающих голый ответ?

Т.е. с более другими, расово верными, языками та же СУБД будет работать быстрее?

Не говоря уже про возможность кешировать что-то в памяти в пределах инстанса.

А кеширование, вероятно, прерогатива корпоративных технологий типа java?

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

По областям если смотреть, то мы получаем картину: а) Конечно, PHP. б) Нет ничего надёжней Java/C#. в)Лучше всего Objective-C под Мак, за ним C++ и замыкает шествие самый скоростной и ненадёжный ЯП - C. Сам по себе C быстр и неплох(как низкоуровневый ЯП - аналог ассемблера). Но он настолько сложен из-за ручного управления памятью и прочих подобных низкоуровневых штучек, что человеческий фактор делает программы на нём бажными, очень бажными.

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

А зачем он нужен, этот python? Чем он лучше PHP? Синтаксис у него уродский, на Basic смахивает. Я не доверяю языкам c отступами.

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

Ага, маленькую. Python - простой и у него много библиотек и привязок к библиотекам на C/C++. Но как язык не фонтан - синтаксис уродский. Да ещё и тормозной он до ужаса. А Ruby - хорошо, но экзотика и документации по нему, как кот наплакал.

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

Ты специально во френды напрашиваешься? Видно ж, что ни строчки кода ни на каком из перечисленных тобой языков не написал. Иди в толкс лучше баб обсуждать.

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

Как сказать. PHP использую если надо изменить шаблон или небольшой плагин к CMS наваять. С фреймворками вроде RoR не знаком, да мне и их идея не очень по душе. Только ActiveRecord мне нравится. Но ORM в пайтон проектах тоже неплохи. С другой стороны, в PHP-фреймворках тоже есть Active Records, в некоторых. Что касается Ruby, я только немного его поковырял. А на python написал пару скриптов, которые можно было написать на баше, и было бы быстрее и проще. Есть ещё приложение на PyQT4, для личных нужд написанное. Которым не с кем делиться не собираюсь, я написал его для себя, исходники сам себе предоставил, значит GPL не нарушал:) Не хочу что-бы надо мной дружно ржали все бравые программисты с многолетним стажем. Я не противник Ruby или Python, просто я не вижу чем они лучше того же Perl, PHP или JavaScript(про прелесть, няшку Scheme я промолчу). И тот же PHP и JS уделывают эти подделки школоты по скорости, особенно JS. Но я жду Dart. В браузере, и на серверах. Это будет очень хорошо, писать на одном ЯП и клиентскую, и серверную части.

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

Я тоже сначала было подумал, что это отказ от wиндов в принципе. Потом дошло, что это отказ от поколения NT. Теперь, похоже наряду с «мастерами установки и настройки» будут «телепаты разработки и отладки»

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

лучше б они short_open_tag удалили...

2 чаю этому господину.

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

очень хорошо писать на одном ЯП и клиентскую, и серверную части.

Если бы это было столь уж волшебным и важным преимуществом, Java давно зарулила бы. Но она сейчас только на серверах большого нета, - а на клиентах разве что в рамках интросетей - более менее плотно крутится. Я думаю гугл обломится, по скольку амбиции заявлены те же, но маркетинговая политика обязывает к терпимости в отношении слабоумных. Они ее уже анонсировали даже: «Сделать язык похожим на существующие для упрощения обучения» В итоге выйдет либо та же Java, только кастрированная, либо java-script с мпх на лбу. Тачанки с возможностями ракетного крейсера не выйдет никак.

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

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

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

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

возможно, релевантно: хотел только что набрать в гугле «количество классов в API», чтобы выяснить, какой язык расширяется быстрее всего, и на этом основании развить тему скорости разработки. Гугл обломал serious-mode, после первого слова дав подсказку «количество дебилов в России».

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

Нет смысла в Java на клиенте. У многих просто нет нужного ПО(Java Plugin). Да и работает иногда кривовато то, что на ней пишут. Я отправляю отчёты(бухгалтерские) в налоговую через специальный сайт. При подписывании документов загружается Java-апплет. И мутит что-то с электронным ключём и данными. Так вот, этот аплет вылетает с ошибкой в линуксе, подозреваю что в Mac OS тоже.

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

Да, google суров. Интересно, это кто же сделал этот запрос таким популярным?

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

Нет смысла в Java на клиенте.

Смысла нет когда необходимая функциональность может быть обеспечена средствами попроще. Однако на ActionScript и Java-Script еще никто по моему не делал клиентов для налоговой. Смысла не сущетвует. Существуют цели и тема соразмерности им используемых средств достижения.

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

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

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

Чёткий довод прост как 5 копеек - обработка строк в perl реализована гораздо удобнее и проще чем в PHP.

Разве preg убрали из пхп? В ченжлоге этого нет, где можно прочитать?

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

очему они так и не заняли серьёзный процент рынка веб-приложений?

не технические причины

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

Почему они так и не заняли серьёзный процент рынка веб-приложений? Нужны ли они вообще?

Покажи АНАЛОГ redmine на php, например.

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

magic quotes в PHP были хороши тем, что подходили для большого количества ситуаций. И в большом количестве случаев проще было их включить, чем городить свой код.

magic quotes в PHP плохи тем, что:

0. поведение устанавливается опционально;

1. изменяет пересылаемые данные при включенной опции, что усложняет их обработку;

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

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