Форум программистов [Powered by Invision Power Board]

Цитата

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

Вы уже, наверное, в курсе, что группа разработчиков ядра PHP 6 встречалась в
ноябре 2005 года в Париже. Это была захватывающая встреча, на которой разработчики
обсудили развитие PHP со своей точки зрения. Прежде чем я начну свой рассказ о
принятых решениях, вынужден предупредить – все что здесь перечислено, это не
«100% решенные вопросы» и в окончательном релизе PHP 6 дела могут обстоять иначе.
Конечно же, все эти моменты будут обсуждаться подробнее, но уже сейчас можно
говорить о перспективах.

Юникод

Поддержка юникода в настоящий момент может быть установлена только на уровне
«per request», т.е. для каждого запрашиваемого файла. Это означает, что PHP придется
сохранять варианты классов, имен методов и функций одновременно в таблице символов
Unicode и в non-Unicode, что, конечно же, увеличивает количество потребляемых ресурсов.
Разработчики решили сделать настройку юникода на уровне всего сервера, а не
запроса. Отключение поддержки юникода, если таковая не требуется, может увеличить
производительность строковых функций до 300% и приложений в целом до 25%. Вынос
настроек в php.ini позволит снять заботу о юникоде с разработчика и переложить ее на
администраторов хоста.

Если вы самостоятельно собираете PHP и несете всю ответственность за ваши серверы,
то вам будет полезно знать, что для PHP 6 потребуются библиотеки ICU (в зависимости
от того, будет ли нужен Unicode или нет).

Register Globals уйдут в прошлое

Попрощайтесь с этой настройкой, она будет окончательно убрана. Такой настройки
больше не будет в php.ini и если вы ее внесете, то получите ошибку уровня
E_CORE_ERROR. Это означает, что PHP 6 наконец-то завершит эру скриптов PHP 3. Это
серьезный, но очень нужный шаг.

Magic Quotes будут исключены

Опция magic quotes будет так же исключена из PHP и при попытке включения такой
настройки, «выскочит» ошибка E_CORE_ERROR. Это повлияет на magic_quotes,
magic_quotes_sybase и magic_quotes_gpc.

Больше не будет Safe Mode

Это понравится тем, кто хостится на серверах с обязательным включением Safe
Mode. Теперь, включение опции будет вызывать ошибку E_CORE_ERROR. Причиной
для этого становится механизм посыла «сигнала опасности», который делает PHP более
безопасным. Сохранится лишь open_basedir.

'var' будет полным алиасом 'public'

Var используется в классах PHP 4. В объектном подходе PHP 5, употребление var
вызывает ошибку уровня E_STRICT. В PHP 6 предупреждение об ошибке будет устранено
и var станет полным синонимом public. Это вполне нормальное решение, однако, те,
кто «подогнал» свои скрипты под PHP 5, сделали в этом плане лишнюю работу.

Возврат по ссылке вызовет ошибку

И '$foo =& new StdClass()' и 'function &foo' теперь вызовут ошибку уровня
E_STRICT.

Будет убрана совместимость с zend.ze1

Ze1 всегда пытался поддерживать старое поведение PHP 4, но не всегда «работал
на 100%», поэтому в шестой версии PHP он будет полностью исключен.

Поддержка Freetype 1 и GD 1 будет убрана

Поддержка обоих (очень-очень старых) библиотек будет убрана.

dl() останется только в SAPI

Каждую функцию SAPI нужно будет регистрировать отдельно и только CLI и
embed SAPI будут работать с этого момента. В других вариантах dl() работать не будет.

FastCGI всегда включена

FastCGI код будет «вылизан» и станет включенным по-умолчанию для CGI SAPI.
При этом, поддержку FastCGI будет невозможно отключить.

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

Помните старые массивы HTTP_*_VARS? Если вы еще не начали использовать
$_GET и $POST, то начните делать это прямо сейчас, потому что в PHP 6 эти массивы
будут вызывать E_CORE_ERROR.

Перемещения расширений

Расширения XMLReader и XMLWriter войдут в дистрибутив и станут доступны по
умолчанию. Расширение ereg для работы с регулярными выражениями переедет в PECL
(т.е. будет удалено из PHP). Это означает, что PCRE будет по умолчанию недоступно и
выключено. Такой шаг делается для включения нового расширения для работы с регулярными
выражениями, основанными на ICU. Чрезвычайно полезное расширение
Fileinfo будет включено в дистрибутив и доступно по умолчанию.

Дополнения к движку PHP

64 битный целочисленный тип данных

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

Goto

Никаких команд goto не будет добавлено. Однако, команда break расширится статической
меткой, поэтому будет возможно написать break foo и это перекинет на метку
foo: в вашем коде.

ifsetor()

Похоже, что мы не увидим эту функцию, что обидно. В операторе ?: можно будет
опускать один параметр, что позволит писать так: "$foo = $_GET['foo'] ?: 42;" (т.е. если
foo является истиной, то $foo будет равно 42). Это сэкономит немного кода, однако будет
не так читаемо, как при использовании ifsetor().

foreach для многоуровневых массивов

Это отличное новшество – вы сможете проходить с помощью foreach по нескольким
уровням массива, к примеру "foreach( $a as $k => list($a, $b))".

{} против []

Сейчас вы можете использовать и {} и [] для обращения к строковым индексам.
Однако, запись {} уже сейчас вызовет E_STRICT в PHP 5.1 и будет полностью устранена
в PHP 6. К тому же, [] частично заменят substr и array_slice и вы сможете использовать
"[2,]" для получения символов от второго и до конца строки. Очень удобно.

Изменения в объектном стиле

Связка static

Будет добавлено новое ключевое слово для доступа к последующей связке –
static::static2(), что позволит управлять static во время выполнения.

Пространства имен

Этот момент остается нерешенным и по сей день. Мой совет – не задерживайте дыхание.

Типизированные значения при возврате из функций

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

Вызов динамческих функций как статических приведет к E_FATAL

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

Добавления в PHP

APC войдет в ядро

Работа APC с байткодом будет включена в основную поставку PHP в качестве
стандарта, но, вероятно, не будет активизирована по-умолчанию, но результаты ее работы
будут стимулировать хостеров включать эту опцию.

Hardened PHP патч

Этот патч выполняет большое количество дополнительных проверок на безопасность.
Разработчики тщательно изучают этот патч и некоторые элементы найдут свое место
в PHP: защита от разделения HTTP-запроса, allow_url_fopen будет разделена на две:
allow_url_fopen и allow_url_include. Первая опция будет по-умолчанию включена, а вторая
– отключена.

E_STRICT войдет в E_ALL

Вау, это серьезная штука! Сообщения об ошибках наконец-то войдут в E_ALL по
умолчанию. Это демонстрирует старания разработчиков научить «лучшей практике программирования
» посредством сообщений «Эй, ты делаешь неправильно!».

Прощайте asp-тэги <%

Будет удалена поддержка ASP-тэгов, но останутся короткие PHP-тэги <? ?>.

Заключение

PHP 6 движется в интересном направлении – разработчики PHP начали направлять
программистов на правильный путь, вместо того чтобы упреждать «так делать не надо,
потому что это устарело». Категоричное искоренение таких моментов как register
globals, magic quotes, long arrays, {} string indexes и call-time-pass-by-references наконец-то
заставит программистов «вычистить» свой код. Плохо ли это? Я так не думаю, но все это
сделает переход на PHP 6 еще более медленным, чем мы наблюдаем с PHP 5 (который
итак происходит ужасно!).

Цитата

Похоже, что мы не увидим эту функцию, что обидно. В операторе ?: можно будет
опускать один параметр, что позволит писать так: "$foo = $_GET['foo'] ?: 42;" (т.е. если
foo является истиной, то $foo будет равно 42). Это сэкономит немного кода, однако будет
не так читаемо, как при использовании ifsetor().

Цитата(Vaulter @ 3.1.2007, 19:06

)

и я не понял, регулярки будут по дефолту офф или он??? smile

Цитата

Issue: Currently we have two extensions dealing with regular expressions, and soon there will be a third one based on ICU.

Discussion: Currently we see some problems with the bundled ereg library in some places due to people specifying --with-regex=system. We also see distributions linking against another library than our bundled one to prevent conflicts with the apache bundled regex library, or the system's one. As most people seem to prefer linking against something else than our bundled version, it seems proper to remove this bundled library. If we remove the bundled library, then we need to make the ereg functions into an extension, otherwise we can not enable them in all cases. Some functionality in the core of PHP also uses POSIX regular expressions, those should be rewritten to use PCRE then.

Conclusions:

   1. We make ereg an extension
   2. The PCRE extension will not be allowed to be disabled.
   3. The core of PHP should be made to work with PCRE so that we can safely disable ereg
   4. We unbundle the regex library

Цитата(Mal Hack @ 3.1.2007, 17:40

)

Юникод

Register Globals уйдут в прошлое

Magic Quotes будут исключены

Цитата(BobiKK @ 25.1.2007, 00:38

)

Абидно, что mutli-threading'а не будет.

Цитата(smartov @ 25.1.2007, 01:01

)

Жаль namespace-ов не сделают smile

Цитата(IZ@TOP @ 2.2.2007, 11:35

)

Ни кто не знает почему Zend Studio 5.2 подсвечивает выражение use?

Цитата(smartov @ 24.1.2007, 23:01

)

Жаль namespace-ов не сделают

Цитата(smartov @ 2.2.2007, 13:26

)

Он ещё и as подсвечивает

Код


foreach ($array AS $key => $value)

Цитата(Opik @ 8.2.2007, 13:19

)

есть патчик специальный

Код

print ($variable) ?: "Hello World";

Цитата(CyClon @ 28.2.2007, 13:32

)

можно будет писать так:

Код


print ($variable ?: "Hello World");

Цитата(Alan @ 6.6.2007, 05:56

)

когда эту прелесть поставят на хостинги... сомневаюсь, что на мой ее вобще когда-нибудь поставят (

Цитата

наверное все-таки вот так

Цитата(Serkys @ 9.6.2007, 03:02)

Поставят на хостинги достаточно быстро. Жаждущих программить под РНР6 будет немало, а у хостеров конкуренция достаточно сильная, чтобы привлекать к себе пользователей чем угодно, в том числе и новой версией РНР.

Цитата

PHP 5 далеко не везде стоит

Цитата

I thought I may have brought this up a long time ago but couldn't find anything in \
the archives. For a long time already I've been thinking about possibly adding a new \
syntax for array(...) which would be shorter. I'd suggest [...]. While I am usually \
not in favor of having more than one way to do things, I think it'd look much more \
elegant especially (but not only) for nested arrays.

So what I'm thinking of is:
array(1, 2, 3) == [1, 2, 3]
array(1, 2, array("foo", "bar")) == [1, 2, ["foo", "bar"]]
array("key" => 1, "key2" => 2) == ["key" => 1, "key2" => 2]

$arr = [1, 2, 3]
vs.
$arr = array(1, 2, 3)

Well enough examples given
I think it's not worth doing unless there's overwhelming support as it's not \
desperately needed. But I'd be interested to hear people's thoughts. It seems \
implementation shouldn't be an issue but I'd have to dive a bit deeper.

http://marc.info/?l=php-dev&m=117057393530217&w=2

Цитата

Только вот наш хостинг все еще сидит на 4-ке, что толку мечтать о 6-й?

Цитата

Вот если компиляция была.. ....в псевдокод

Цитата(artuska @ 9.11.2007, 14:19

)

Впервые слышу.

Цитата(skyboy @ 9.11.2007, 14:35

)

Вот один из результатов поиска: результат.

Код


$param = @$_POST['param'];

Цитата(Diesel Draft @ 13.12.2007, 13:23

)

Работать быстрее оно точно не начнет.

Цитата(smartov @ 12.12.2007, 19:05

)

не сделают

Цитата

Типизированные значения при возврате из функций

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

Цитата(Fally @ 17.12.2007, 14:15

)

Типизированные значения при возврате из функций

Код


$int = new SplInt();
$int = 5;
$int = "Hello"; // Тут будет вы брошен экзепшен

Код


class StrongTyped extends SplType
{
   public $a;
   public function __construct($a = 0)
   {
      $this->a = $a;
   }
}
$obj = new StrongTyped();
$obj = new StrongTyped(5);
$obj = new stdClass(); // Тут будет выброшен экзепшен

Цитата(nerezus @ 11.1.2008, 15:05

)

Сейчас пока что IDE не предлагают автодополнение после ->

Цитата(sTa1kEr @ 11.1.2008, 13:12)

Цитата(nerezus @ 11.1.2008, 15:05

)

Сейчас пока что IDE не предлагают автодополнение после ->

В Zend Studio прекрасно работает авто дополнение основываясь на PHPDoc-ах.

Цитата(KLeonid @ 12.3.2008, 06:09

)

А мне и на 4ке неплохо живется

Цитата(KLeonid @ 12.3.2008, 07:09

)

А мне и на 4ке неплохо живется . И пока не собираюсь переходить на PHP5.

Цитата(Serkys @ 12.3.2008, 13:13

)

Если бы все были такими, как ты - ты бы до сих пор в пещере сырое мясо ел

Цитата(MuToGeN @ 22.6.2008, 02:49

)

ИМХО, в E_ALL не хватает бита E_STRICT, с этим криворуких программистов стало бы на порядок меньше.

Цитата

Если вы еще не начали использовать
$_GET и $POST, то начните делать это прямо сейчас, потому что в PHP 6 эти массивы
будут вызывать E_CORE_ERROR.

Код


if (isset ( $_POST['ok'] ) ) {}

Цитата(Feldmarschall @ 29.6.2008, 06:37

)

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

Цитата(Sniper @ 29.6.2008, 09:57

)

т.е выбросят только $HTTP_GET_VARS и $HTTP_POST_VARS, а $_GET и $_POST $_SESSION $_FILE итп оставят в покое?

Цитата(Sniper @ 29.6.2008, 09:57

)

ничего не понятно. если ещё не начали их использовать, то и не используйте.... smile

Цитата(Sannis @ 29.6.2008, 07:07

)

Где написано "не используйте"? Как раз написано использовать их.

Цитата(sTa1kEr @ 11.1.2008, 13:38

)

Покопайтесь в мало известном расширении spl_types

Цитата

Лично я хотел бы увидеть полную поддержку OO и OO стиля. Я понимаю, что для этого нужно коренным образом изменить движок, т.е. сделать проверку во время компилляции. Да, это сложно. Но тогда возникла бы возможность уверенно писать чистый и понятный, а главное - более правильный код. Изчезла бы целая куча if, (int) и тому подобного. Мы бы точно знали, что вводить, и что получим. Например, конструкция enum бы не повредила (как тип), а многие скажут "зачем, ведь есть массивы".

Цитата

На Java я писать ещё не готов