Pull to refresh

Comments 96

>оператор ??
Побыстрее бы его в Java/C# ввели, очень удобная штуковина :)
Эм, как бы в C# он уже есть (см. Null coalescing operator)
C#:
// Set y to the value of x if x is NOT null; otherwise, 
// if x = null, set y to -1. 
int y = x ?? -1;
// Assign i to return value of the method if the method's result 
// is NOT null; otherwise, if the result is null, set i to the 
// default value of int. 
int i = GetNullableInt() ?? default(int);
класс :)
java как всегда не торопится )
в Groovy есть Elvis-оператор "?:"
elvis это другое кстати в php от тоже есть
ну у меня кармы не хватает ссылками отвечать:

def g = false // 0, ''
def v = g ?: '123'

а ?? это только null, в php ещё и с обработкой isset
вон вы про что. согласен — есть отличие.

ЗЫ: чуть поправил карму
В текущем php (5.6) есть возможность использовать тернарный оператор без второго операнда, что позволяет уже создавать аналогичные конструкции вида:
$action = $_POST['action'] ?: 'index';
а если в $_POST['action'] будет false?)
все-таки основной смысл ?? в обработке null, что больше проблема компилируемых языков
А если $_POST['action'] не существует, то вообще будет notice.
Только вот будет notice, если в посте нет action
Тут уже отвечали, что там может быть false, 0, «0», пустой массив. И эти значения будут проигнорированы. В любом случае здесь будет ошибка, а ошибки лучше не глушить, а избегать. Тем более @ — затратный оператор, он устанавливает error_reporting в 0 перед вычислением выражения.
Не написали очень важное изменение, что PHP для Windows x64 наконец-то начал представлять целые числа в виде 64-х битных, а не как раньше, 32-х, что делало использование х64 сборок на Windows бессмысленным занятием, если нужны манипуляции с большими числами.
Вот разработчикам фреймворков и CMS веселья добавилось :)
На самом деле значительных обратно несовместимых изменений не так уж и много.
Ну с релизом PHP 7 каждый разработчик захочет ускорить свои приложения. Вот тогда уже 5.6 будет постепенно отходить.
Итерация по массиву при помощи foreach() больше не сдвигает внутренний указатель массива, который можно получать и изменять при помощи функций current()/next()/reset() и им подобных.

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

$array = [1,2,3,4,5];
next($array);
var_dump(current($array)); // 2

foreach ($array as $item) {
    continue; // iterate over array
}

var_dump(current($array)); // 2. В PHP 5.5 будет FALSE


3v4l.org/nf3Cg
UFO just landed and posted this here
Как бы ничего нового глобального я в списке не увидел. Разве что «увеличение производительности» — на что еще тоже нужно будет посмотреть. Кстати, стало интересно, а кто и зачем юзает пых под виндой?
Да и не совсем понятно зачем было перескакивать через 6 версию. Между 5.0 и 5.6 было даже больше изменений в самом языке, но возможно в движке их действительно много. А пых под виндой, для тестов, для разработки, а еще же есть IIS.
Ну для тестов и разработки давно уже многие (как и я) используют виртуалки — после того как несколько раз нарвался на грабли, что под виндой работает, а на продакшене болт. А заводить пых под иис, на мой взгляд, вообще изврат.
Насколько я помню, это объяснялось тем, что в PHP6 предполагали вводить совсем другие изменения (в частности, родные Unicode-строки). И, как водится, появилось огромное количество книг и статей с названиями типа «Программируем на PHP6», несмотря на то, что изменения даже утверждены еще не были.

Поскольку roadmap сильно изменился, чтобы не вводить в заблуждение пользователей, решили перепрыгнуть через цифру.
Иногда этого требует архитектурное решение.
>Как бы ничего нового глобального я в списке не увидел
Так это 7.0 заморожен по фичам. А вот в будущих 7.* вполне могут быть новые изменения.
И ещё, очень важного изменения в списке в статье нет — это скалярный type-hint, и это немалая вещь, это серьёзно (хотя в некоторых случаях и не настолько полезно).
Не нашел этого в указанном в источниках документе. Хотя в кратком обзоре это есть. Добавил, спасибо.
Этот список — то что влияет на уже существующий код. То есть маленькие BC-брэйки. Помимо того что полностью переписали все что связано с основными структурами, вот вам кратенький список плюшек нового PHP:

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

ну это то что я вспомнил из существенного для меня лично.

wiki.php.net/rfc#php_70 — тут подробнее.
> Добавлен новый оператор сравнения <=>, так же известный как «spaceship operator». Конструкция $a <=> $b возвращает -1, 0 или +1 если $a соответственно меньше, равно или больше $b. Удобно использовать в колбэках для usort().

Хоть убейте, не понимаю, зачем алгоритму сортировки знать больше, меньше или равно, если достаточно сравнения <. Да и трындеть из всех сил о бардаке в языке, но вместо була вернуть инт, это конечно норм.
UFO just landed and posted this here
В C++ boost есть tribool, надо такой вводить.
Точно, нужно еще ввести булевые значения с сарказмом.
тайп хинт!

(сарказм) $var
зачем алгоритму сортировки знать больше, меньше или равно, если достаточно сравнения <
Заинтриговал ваш вопрос, поэтому провел небольшое расследование. Похоже, что сейчас PHP использует свою реализацию алгоритма Quicksort, в котором отдельно не используется информация о равенстве сравниваемых элементов. Но ранее (PHP 4) он использовал стандартную Си функцию qsort из stdlib, которая, в качестве одного из аргументов, как раз принимает функцию сравнения, возвращающую -1,0 или 1.
Надеялся сказать что-то умное, но неожиданно для себя выяснил, что в PHP алгоритмы сортировки неустойчивы.
Так что, видимо, незачем.
>Так же foreach по значению теперь всегда работает с копией массива.

Я надеюсь там что-то вроде CoW?
Совершенно не показательный, но забавный сравнительный тест hello world :)

image
Строго говоря, это тест не hello world, а времени выполнения eval()
У меня на реальном проекте семерка по сравнению с 5.6 показывает на треть лучший результат. Две секунды вместо трех
Добавлен оператор "??" (Null coalescing operator), позволяющий проверить переменную на существование

Да! Еще больше запутанного говнокода!

В качестве значения констант, объявляемых через define() теперь можно указывать массивы.

facepalm

Синтаксис конструкторов в стиле PHP 4 (имя метода конструктора совпадает с именем класса) теперь считается устаревшим.

ДАНЕУЖЕЛИ!

Удалена INI директива «asp_tags

Это надо было сделать еще в 5.3

Добавлена поддержка type-hint'ов для скалярных типов. Ранее контроль типов был возможен только для классов, интерфейсов, массивов и типа callable.

Единственное, что радует.

И еще: где обещанная строгая типизация?
Кто вам обещал строгую типизацию?
О ней еще при живой четверке кричали на всех углах.

Мне даже любопытно, кто и за что минусит?
Не будет никогда строгой типизации, потому что динамическая/нестрогая типизация — это ни хорошо и ни плохо, это просто динамическая/нестрогая типизация. Не нравится, есть миллион ЯП со строгой/статической типизацией.
Есть также понимание того, что нестрогая типизация — хороша для сохранения рабочих мест, но плоха, когда хочется написать что-то работающее без ошибок.

Между языками с «динамическая/нестрогая типизацией» и «статической/строгой типизацией» лежат ещё языки с «динамическая/строгой типизацией» (от LIPA до Python'а) и практика показывает, что от нестрогой типизации выигрыша почти никогда нет, зато слёз — куча.
где обещанная строгая типизация?


<?php

declare(strict_types=1);

function foo(string $bar) : string {
    return $bar . $bar;
}

foo(123); // error


по умолчанию будет произведен каст (в случае если каст идет с потерями — ошибка), в «строгом» режиме все что не соответствует нужному типу — ошибка.

wiki.php.net/rfc/scalar_type_hints_v5
Это больше на костыль похоже, если честно.
Давайте назовем это «компромисом», не так грустно будет. По другому этот RFC просто не приняли бы, причины собственно там описаны.
>>В качестве значения констант, объявляемых через define() теперь можно указывать массивы.
Только define как был медленным, так и остался, вплоть до того что доступ к массиву по текстовому ключу быстрее чем по константе define. Писал об этом ранее habrahabr.ru/post/257237/#comment_8415927
Type-хинты радуют. Не знал о том, что можно было указывать на callable. Здесь подразумевается closure или строку и массив тоже можно подсунуть под видом callable?

Прямо сегодня столкнулся с тем, что shr не трогает старший бит. Зачем так сделали? Неужто все эту операцию только для деления на 2 используют?
ответил чуть ниже…
Здесь подразумевается closure или строку и массив тоже можно подсунуть под видом callable?

Читаем документацию. Все что валидно для call_user_func.

Еще интересная штука, которая появилась в PHP7 но о чем не написано в статье (она написана на базе информации для обновления, новых фич тут как бы и не описано вовсе) — анонимные классы. То есть теперь можно упарываться почти как в java для описания колбэков, реализующих интерфейсы:

<?php

interface FooCallback {
    public function __call(string $foo, string $bar) : string;
}

function foo(FooCallback $foo) : string {
    return $foo('foo', 'bar');
}

foo(new class implements FooCallback {
    public function __call(string $foo, string $bar) : string {
         return $foo . $bar;
    }
});


что-то в этом духе.

wiki.php.net/rfc/anonymous_classes
Люди, а объясните, что значит «Так же foreach по значению теперь всегда работает с копией массива»?
В теле цикла foreach теперь не получится производить манипуляции над самим массивом.
Как я понял, наоборот, можно менять оригинальный массив, но foreach будет идти по старому, не измененному.
Да, при передаче массива в foreach теперь происходит копирование (как при передаче аргументов функции). Естественно Copy-on-write никто не отменял и если вы не меняли массив в цикле то реально копирование происходить не будет.
Сам отвечу на свой вопрос. Судя по wiki.php.net/rfc/php7_foreach, массив $a изменится после завершения цикла (как и сейчас в ПХП5).
А речь вообще о другом. А именно, о том, как ведет себя текущий перебор массива в цикле foreach в том случае, если внутри цикла происходит модификация этого массива.
Сейчас в некоторых ситуациях поведение довольно странное. В ПХП7 хотят это поведение сделать предсказуемым.
Но даже сейчас, в 5.6, если в теле цикла добавить элемент в массив, цикл его не затронет. Если изменить элемент, то цикл все равно получает неизмененное значение. Вот пример с пояснениями:

$a = [0, 1, 2];
foreach ($a as $item) {
	if ($item === 1) {
		$a[2] = 3; // Изменяем следующий элемент
		$a[] = 4; // Добавляем элемент в конец
		// $a теперь равно [0, 1, 3, 4], но цикл по прежнему выдает 0, 1, 2.
	};
	echo $item, ' ';
};
print_r($a);

Результат:
0 1 2 Array
(
[0] => 0
[1] => 1
[2] => 3
[3] => 4
)
Да, так и есть. Вот я и не могу понять, что значит «foreach по значению теперь всегда работает с копией массива»
Вроде как он и в 5.х работает с копией. Тут некоторые говорят, что вообще нельзя будет в теле foreach производить манипуляции типа $a[1] = 2. По-моему это странно.
Двадцать раз уже на хабре написано, что нового в PHP 7.
Написали бы конкретно, какие в альфе нюансы.
Дайте пожалуйста ссылочки на несколько из двадцати статей, поиском не нашёл.
habrahabr.ru/search/?q=php7
а вот так (с пробелом) не находит habrahabr.ru/search/?q=php%207
спс.
Ну а теперь еще бы дождаться расшиерние под 7ку. Редиса очень не хватает.
Конечно все замечательно, но такими темпами язык все больше и больше отстает от жизни.
Можно как-то аргументировать?
Ну, во первых, на мажорную версию такой список совсем не тянет.
Конечно, на самом деле, изменения глобальнее, но все равно.

Давно пора уже самому языку стать объектным.
Понятно, что обратная совместимость и куча стона «не ломайте наш язык» и мегатонны кода, но хотя бы с возможностью переключателя (для тех, кому хочется). Сообщество огромно и необходимый код, уверен, мигрировал бы на новый синтаксис достаточно быстро.
А так — это топтание в болоте.
Итак у языка репутация уже ниже плинтуса.
По поводу мажорной версии, в статье описаны только изменения самого языка, но есть еще очень много существенных изменений в ядре.
По поводу сделать объектным сам язык — это был бы уже совсем другой язык и другая история. А может быть когда нибудь будет.
Мне кажется, вопрос, как раз и в этом — назрело уже. Либо меняешься, либо умираешь.
Объекты в языке же появились в связи с развитием программирования — ничего страшного с языком и его популярностью не случилось, только лучше для всех стало.
С популярностью ничего не стало потому что все эти новомодности типа объектов можно тупо игнорировать — и при этом свои поделки как-то таки прождать. Если у PHP отнять это свойство и сделать так, что для использования языка его придётся изучать, то кому он такой будет нужен? Вы же убьёте единственное его достоинство — возможность программирования с помощью применения генетических алгоритмов к ответам на Stack Overflow без задействования головного мозга!
Да через Stack Overflow будут уже новый синтаксис копировать — делов то )
А кто старый оттуда изведёт и, главное, породить тысячи нового? Посмотрите на python — там вроде публика чуть больше думать приучена, а невозможность использования старого кода обозначает, что за многие годы, прошедшие с выхода python 3 на него пересели единицы.

Убирать из языка можно только то, что уже почти никто не использует, да и то с осторожностью, это ещё разработчики FORTRAN'а выяснили, когда попытались несколько фич выкинуть в FORTRAN 77!
Убирать не обязательно. Сделать параллельный синтаксис и опциональную возможность отключения в php.ini старого.
Надо же что-то с этим делать.

Миграция кода — не проблема в наше время.
Миграция кода — не проблема в наше время.

я бы хотел жить в вашем времени.

Сделать параллельный синтаксис

Сколько там чуваки мигрировали с Python2 на Python3?
Сделать параллельный синтаксис
Сколько там чуваки мигрировали с Python2 на Python3?
А причём тут Python? Как раз там никакого параллельного синтаксиса никто не сделал: вы не можете ни включить в проект на Python2 модуль написанный для Python3, ни наоборот.

Тут скорее нужно как раз на тот же FORTRAN смотреть, только на FORTRAN 90. Он как раз предложил новый синтаксис, в котором не нужно считать колонки — и им даже многие начали пользоваться. А многие (хорошо если не большинство) — по прежнему используют fixed form! А уж найти хоть одного программиста, который бы на фортране или коболе писал бы объектно-ориентированные программы мне не удалось. Хотя оба языка поддерживают OOP уже многие годы.

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

Давно пора уже самому языку стать объектным.

Тип все что вам нужно для счастья это что бы инты были объектами? И что вы будете делать? Наследоваться от интов? Примешивать поведение вы всеравно не сможете (во всяком случае пока, и я думаю это была бы опасная вещь в руках по-ха-пэшников).

Если только с точки зрения синтаксиса — раньше у PHP был крайне неуклюжий парсер и это сделать было просто невозможно. С 7-ой версии там уже нормальный парсер, даже местами контекстно зависимый и заимплементить это дело в принципе уже можно. Не превращать скаляры в объекты а просто синтаксис сделать схожий. Так же есть предпосылки для более глубоких оптимизаций на уровне генерации опкодов, аля алиасы для функций которые просто вызывают php-шные функции не будут добавлять оверхэда вообще, потому как на уровне опкодов мы не будем дергать лишние функции. А это значит что можно будет вместо резкого перехода сделать полифилы, шимы и т.д. которые и на производительность сильно влиять не будут и помогут проще перейти на новый синтаксис или просто добавить вариант использования.

Итак у языка репутация уже ниже плинтуса.

Она ниже плинтуса не потому что язык плохой, я бы так не сказал, а потому что любой идиот может на нем что-то написать. Именно по этому в PHP комьюнити так много индусов и быдла. Скажем возьми человек Python или Ruby ему придется чутка побиться головой и почитать документацию. А с PHP берешь и кодишь всякий треш, и мнишь себя гением. И добрая половина просто не считает необходимым развиваться куда-то дальше начального уровня. Таких людей хватает и в Ruby и Python сообществе, но процент сильно меньше, так как в самом начала всеравно придется чуть чуть поднапрячься. А затем кривая обучения идет примерно одинаково, По количеству же толковых разработчиков я думаю разницы особо нет.
Тип все что вам нужно для счастья это что бы инты были объектами?

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

А будь все объектно, стабильно и единообразно, так глядишь и быдлокодеры подтянулись бы по качеству.

Она ниже плинтуса не потому что язык плохой, я бы так не сказал, а потому что любой идиот может на нем что-то написать.

Да нет, не от того, что пишут плохо. Это в любом языке можно сделать. Мы вот пишем и на Ruby и на PHP — что ж мы на Ruby специально пишем хорошо, а на PHP плохо? )

А все из-за того, что синтаксис нелогичный, груз обратной совместимости, реализация функций с багами (да, конечно, тянется из сишных библиотек, но от этого не легче).
От того, что в языке нет никакой системы пакетов и расширений (не для самого языка — для проектов на нем) — приходилось копипастить, отсюда и быдлокодерство.

Отчего тот же композер не зашить в сам язык? Почему нельзя сделать сборку языка с библиотеками попроектной — в самом языке?
От того, что системно язык не организован — невозможно поставить произвольную версию под проект, не говоря уже про несколько версий одновременно (да, есть phpbrew, но попробуйте с ним построить нормальный продакшн — проще уж виртуализировать),…

Аналоги инструментов появляются, все-таки опенсорс великая штука, но все они всегда хуже конкурирующих продуктов других языков. В основном, за счет организации как раз самого языка.

Единственная и последняя опора PHP — виртуальный хостинг — возможность размещать проекты на нем на хостинге за $5 в год без необходимости иметь хоть какого-то сисадмина. В этой нише с PHP пока не может полноценно конкурировать ни один язык, поэтому PHP и остается пока лидером.

Конечно вопросы решаются и объекты какие-никакие появились, и нэймспэйсы, но все надо оценивать в сравнении.
По сравнении с конкурирующими технологиями PHP огромными скачками несется в прошлое — с каждым днем «отстает от поезда» все больше и больше.
А будь все объектно, стабильно и единообразно, так глядишь и быдлокодеры подтянулись бы по качеству.
Неа. Ушли бы куда-нибудь на другой язык.

Да нет, не от того, что пишут плохо. Это в любом языке можно сделать. Мы вот пишем и на Ruby и на PHP — что ж мы на Ruby специально пишем хорошо, а на PHP плохо? )
Да. Естественный отбор, однако. Достоинство PHP является прямой причиной всех его недостатков: он был задуман так, чтобы человек, ничего не знающий о программировании, смог бы сделать работающую программу. Конечно в ней будет куча косяков, но она будет работать! А значит её можно отдать заказчику и пойти делать следующий сайт за 5 копеек.

По сравнении с конкурирующими технологиями PHP огромными скачками несется в прошлое — с каждым днем «отстает от поезда» все больше и больше.
Никуда он не отстаёт. Свою нишу (язык для людей, которые либо не могут либо не хотят научиться грамотно программировать) он занимает прочно, а никакую другую ему занять не светит, так как их уже давно заняли другие, более аккуратно сделанные языки.
Неа. Ушли бы куда-нибудь на другой язык.

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

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

Только за счет возможности работы на дешевом виртаульном хостинге. Это последнее конкурентное преимущество.

Т.к. количество кода в наше время уже не является преимуществом.
Помню, как в свое время говорили, что у Windows Mobile огромное конкурентное преимущество за счет огромного количества написанного кода, а через год все работало уже под андроидом и ios и про WM никто уже даже и не вспоминал.

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

Поймите вы: если человек понимает почему, скажем, в python'е (просто пример приличного языка, который я хорошо знаю) "10" < "5" — это True, 10 < 5 — это False, а "10" < 5 — это вообще TypeError (исключение, которое, если его не поймать, обрушит всю программу), то ему, конечно, хочется от языка некоторой стройности.

Но подавляющее большинство людей этого не понимают и понимать не хотят. А говнокодить-то хочется.

И вот для них сейчас PHP — лучший выбор. А поскольку их — гораздо больше, чем программистов на многих других языках, то и разработчики библиотек и расширений (которые, в большинстве своём, всё-таки способны такие вещи понять, да и вообще — программировать-то умеют) без работы не сидят.

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

Посмотрите количество гемов под рельсы и сравните с любыми модулями и бандлами для PHP-фреймворков.
А вы лучше посмотрите на количество сайтов на которых что-то такие крутится на основе WordPress'а (или, ещё того хуже, phpBB). Ни о каких гемах их разработчики (в большинстве своём) даже не мечтают!

PHP — это VisualBasic наших дней. Когда Microsoft решил «осовременить» Visial Basic и предложил программирующим на нём (которые в те времена составляли чуть ли не половину вообще всех людей, которые что-то там программировали) VisualBasic.NET со всякими новомодными плюшками, но люди их «ниасилили». Кто-то переключился на PHP, кто-то переквалифицировался в VBA-программистов, кто-то «закусил удила» и выучил-таки C#, но разбежались в разных направлениях почти все. Вся экосистема была уничтожена почти под корень за считанные годы.

Помню, как в свое время говорили, что у Windows Mobile огромное конкурентное преимущество за счет огромного количества написанного кода, а через год все работало уже под андроидом и ios и про WM никто уже даже и не вспоминал.
Дык правильно говорили. Во-первых через год ничего почти не работало (это я вам как человек, ходящий с Android'ом с 2008го года говорю). А во-вторых — это пример вообще не из той оперы: первые несколько лет много людей по прежнему пользовались телефонами на Windows Mobile и Symbian'е, так как под них нужный им софт был, а больше ни подо что не было, а потом Microsoft удавил сначала Windows Mobile (Windows Phone 7 использовал ядро от Windows Mobile, но старые программы использовать было нельзя), а потом внедрил своего засланного казачка в Nokia и Symbian тоже удавил. Разумеется если платформу насильственным образом убили, то количество софта под неё уже никакой роли играть не может!

У меня вообще есть ощущение, что весь проект Windows Phone (и особенно — с привлечением Nokia) был задуман и осуществлён как грандиозная диверсия. Потому что даже если кто-то решил бы специально уничтожить всех реальных конкурентов Android'у, то ничего лучше было придумать просто нельзя.
> но процент сильно меньше
не факт, я видел много людей которые делали треш на ruby, java, c#. тут ещё общее кол-во вовлеченных влияет. как не крути а php популярен.

но вообще clockworkbird года на 2-3 опоздал с «топтанием». по поводу объектности языка не оч. понятно что имелось ввиду. да вы бы первый и плевались от этой объектности — когда $a->round(2) падает так как вы не сделали кастинг в int.
и кстати в 7 есть и переключатели для пары фич.
Да не я опоздал, а PHP походу )
Я с 3 версии работаю (после perl это был глоток свежего воздуха), а с 5 версии все жду — когда же, когда. Шестого не будет, ну ладно, ну в 7 то уже точно… Ага, щас — __constructor отменили, все дела.
Уже и с любимого PHP на Ruby переполз местами, уже заказчики в ответ на предложение сделать проект на PHP-фреймворке пишут: «Опять ты мне какое-то г@#$о прелагаешь»,… и чувствую — не дождусь.
Sign up to leave a comment.

Articles