Нововведения в PHP 5.6 beta 3

  • Tutorial


Так как PHP — развивающийся язык, то я расскажу об уже реализованных возможностях в третьем бета релизе версии 5.6. По сути, эта публикация — дополнение к предыдущей: "Функции в PHP 5.6 — что нового?".

Магический метод __debugInfo().


Возвращает массив, в котом содержится любая информация добавленная разработчиком. Вызывается в том случае, когда объект передается в качестве аргумента, например, в функцию var_dump().

Пример:

namespace Application;

class Test
{
    public $prop = 200;

    public function __debugInfo()
    {
        return [1];
    }
}

var_dump(new Test);

Результат выполнения:

object(Application\Test)#2 (1) {
  [0]=>
  int(1)
}

Примечание:

Если в возвращаемый массив поместить переменную $this, то вы войдете в бесконечный цикл. :)

Экспоненциальный оператор **.


Здесь, уверен, все понятно и без описания. Простой оператор в виде двух астерисков экспоненциально увеличивающий значение числа.

Пример:

$exponent = 2 ** 4;
var_dump($exponent); // int(16)
$exponent **= 2;
var_dump($exponent); // int(256)

unset($exponent);

$exponent = ~2;
var_dump($exponent); // int(-3)
$exponent **= 2;
var_dump($exponent); // int(9)

Примечание:

Также это работает и с GMP.

Пример:

$base = gmp_init(2);
var_dump($base ** 3); 

Результат выполнения:

object(GMP)#3 (1) {
  ["num"]=>
  string(1) "8"
}

Языковые конструкции use function и use const.


Импорт функций и констант (из пространств имен) — это как импорт классов — круто. На первый взгляд. Когда доходит до дела, то работает оно, по крайней мере сейчас, плохо.

Пример:

namespace Application
{
    const TEST = 2 * 4;
    function test()
    {
        return TEST;
    }
}

namespace
{
    use const Application\TEST;
    use function Application\test;

    var_dump(test(), TEST);
}

Результат выполнения:

int(8)
int(8)

Вроде бы и неплохо, но нет автозагрузки — она реализованна только для классов. Так что данное «улучшение», сейчас, только добавляет необходимость использовать дополнительный синтаксис. Отныне, если указано пространство имен, то к функции невозможно обратиться даже выполнив include (или require) файла в котором она содержится и придется еще дописать use function Name\Space\the_func. А если функций много..?

Улучшенная автозагрузка классов.


Это, правда, было исправлено еще в версии 5.5, но упомянуть стоит.

Пример:

spl_autoload_extensions('.php');
spl_autoload_register();

Ранее, вышеприведенный код работал бы только на компьютере под управлением ОС семейства Windows. Но почему? Все просто. Разделитель вложенности у пространств имен — это символ "\", а в win-системах это еще и разделитель директорий и он отличается от оного в unix системах. По этому-то ранее приходилось делать что-то подобное:

spl_autoload_register(function ($class_path) {
    require_once str_replace('\\', '/', $class_path) . '.php';
});

Указана кодировка по умолчанию.


Отныне, input_encoding, output_encoding и internal_encoding, по умолчанию имеют значение "UTF-8".

Обо всех реализованных возможностях можно прочесть перейдя по ссылке: wiki.php.net/rfc#php_56

Similar posts

AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 13

    +22
    Экспоненциальный оператор? Мне всегда казалось, что это называется «возведение в степень», а экспонента — это когда в основании степени е.
      +12
      „экспоненциально умножающий числа“ — это шедевр.
        +3
        это кто так a**b = exp(log(a**b)) = exp(b*log(a)) ;)
        +2
        Unicode в планах хоть есть?
          –2
          Больших проблем и так нет.
            +3
            Был. Эдак где-то в году 2006-ом… А если серьёзно, то забудьте про юникод в ядре и почитайте статью habrahabr.ru/post/138269/
              –1
              Чем вас не устраивает использование UTF-8 повсеместно? Не понимаю, что плохого если все методы будут явно использовать ByteArray в виде UTF-8?
              Кстати говоря взгляните сколько проблем с Unicode появилось в Python? А неумение пользоваться этим ставит надежность и необходимость применения под сомнение.
              Хотя сложно представить где действительно нужен UNICODE. Приведите пожалуйста конкретные проблемы где не обойтись и как внедрение UNICODE решило бы проблему?
                0
                Эм… а где unicode не нужен? Данные в базе хранятся обычно в нем, клиенту так же в нем отдаются. Следовательно весь код обрабатывающий данные работает с юникодом так или иначе. Другой вопрос, что это не нужно делать на уровне ядра, и мне сложно придумать задачи при которых поддержки юникода в php не хватает. Регулярки замечательно с ним работают, для всего остального есть mb_string. Вообще в большей части приложения что-то сложное делать с текстами не приходится, так что опять же проблемы нету.
                  0
                  > Данные в базе хранятся обычно в нем, клиенту так же в нем отдаются.

                  Как хранятся данные в базе данных мы с вами не знаем (по хорошему внутри движка СУБД это как-то «хитро» реализовано), но вот получаем мы их в виде массива символов кодированных в UTF-8 (не путайте UNICODE и данные в кодированном виде).

                  Клиенту мы отправляем так же данные кодированные в виде UTF-8.

                  Таким образом мы еще не разу не столкнулись напрямую с обработкой данных в UNICODE. Которая вероятно где-то скрыта внутри вашей бизнес логики.

                  А теперь внимание вопрос, а какие сложные операции по работе со UNICODE есть в вашей бизнес логике? Подстановка, количество элементов? Вы сами отвечаете на вопрос, что нет особой проблемы в использовании регулярных выражений и mb_ функций.

                  > Вообще в большей части приложения что-то сложное делать с текстами не приходится, так что опять же проблемы нету.

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

                  P.S. На случай же когда речь идет о невозможности использовать строки на уровне приложения в удобном ООП стиле, так
                  кто мешает создать класс Unicode и реализовать в нем все чего вам не хватает? Появиться ваша собственная прослойка для работы
                  с Unicode.
                    0
                    Я ничего и не спрашивал собственно. Вы видимо меня не поняли, я интересовался больше «а что php сейчас не может такого делать что столько шума»? Опять же я указал что для подавляющего большинства проектов такой уж сложной работы со строками и нету (если мы про бизнес логику), а все мало мальски простое и так хорошо работает.

                    Что до «не путайте», мне всегда казалось что юникод он и в африке юникод, а UTF-8 это один из вариантов представления. Так что от этого это не-юникодом не становится.

                    Что до «удобного ООП стиля», это то тут вообще причем? Для этого нужно что бы сами строки были объектами или реализовывать враппер для этого. Мне если честно и с функциями норм.
                      0
                      Fesor, собственно реакция скорее на "-1" к комментарию, а вашу позицию разделяю и с ней согласен.

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

                      P.S. А к UTF-8 так это вариант представления (давайте называть его бинарным представлением UNICODE или способом кодирования UNICODE) и разделять эти понятия, так как массив байт ByteArray с UTF-8 и объект строка в UNICODE разные объекты. Разница будет видна в индексной адресации (скажем утверждение unicodeStrInUTF[0] != unicodeStr[0], так как в первом случае по первому индексу будет «char_t», а во втором «wchar_t» (сейчас вроде это — int) в терминах C/C++). Я бы сказал разного порядка объекты.
              0
              Прошу прощения за возможно школьный вопрос, но как из 2 получается -3?

              unset($exponent); // удалили переменную(null)
              $exponent = ~2; // Этот момент не понятен
              var_dump($exponent); // int(-3)
                0
                Разобрался:
                ~2 = -3
                равно:
                ~x = -x — 1

              Only users with full accounts can post comments. Log in, please.