Как стать автором
Поиск
Написать публикацию
Обновить

Комментарии 22

Печально, что не взялись за нативные аннотации в php7.
Имхо аннотации в docblock это дико даже для php :)
Всего голосов 2: ↑2 и ↓0+2
Меня самого передергивало каждый раз когда добавлял аннотации, когда тестировал друпал8, но хоть это и противно зато показалось очень удобным. Но реализация хромает это точно.
Комментарий пока не оценивали0
Чувак, спасибо тебе и респект за работу!
Всего голосов 9: ↑9 и ↓0+9
Кажется еще не было
mgdm.net/weblog/php-at-the-speed-of-c/
как мужик код расчета мандельброта ускорял в 2100% раз, пересобрав его phpшной либо в «развернутый» php код, а потом собрав его в виде расширения
Всего голосов 1: ↑1 и ↓0+1
Спасибо за выпуск!

Ребята, кто в теме, такой вопрос. А какие реальные минусы у PHP 7? Ну, по сравнению с PHP 5. Сам на PHP не пишу, но стараюсь быть в курсе событий :)
Всего голосов 2: ↑1 и ↓10
Минусы? Нет минусов, это же один и тот же язык, а не альтернатива. Для некоторых обрезание устаревшей функциональности может быть проблемой (она была объявлена устаревшей заранее), но любой нормальный код с 5.5/5.6 на 7 запустится без проблем.
Всего голосов 6: ↑6 и ↓0+6
Return Type Hints реализованы ужасно, и их использовать в таком виде пагубно для кода. Основные вещи:
1. Нет Nullable при возврате:
public function find($id):User {
    return null;
}

Приведет к Fatal Error (хотя в нормальных языках возврат null нормальное явление)
2. Нет «уточнения»
interface EntityInterface {}
interface EntiryRepositoryInterface {
    public function find($id):EntityInterface;
}
class User implements EntityInterface {}
class UserRepository implements EntityRepositoryInterface {
   public function find($id):User {
   }
}

Это также Fatal Error
3. Переопределение класса и возврат this также не дает указать что мы возвращаем объект насследника, мы указываем тип предка, то-есть автодополнение будет считать что это предок.

В общем в текущем виде Return Type Hints вообще неюзабельны для классов, но могут нормально использоваться только для скаляров. Пара примеров еще: делал для доклада о HACK vs PHP 7
Всего голосов 3: ↑3 и ↓0+3
Благодарю за ответ.
Комментарий пока не оценивали0
Всё это будет исправлено в следующих минорных релизах, как и возврат void
Всего голосов 2: ↑2 и ↓0+2
Ну я могу сказать по каждому из пунктов:
1. RFC про Nullable зарегистрирован очень давно, но в обсуждении решили что эта вещь почему-то не нужна, и предложили выкидывать Exception'ы, хотя обещали подумать.
2. От этого отказались после первого варианта RFC где это было возможно, из-за того, что поведение не похоже на поведение входящих переменных (там тоже нет «уточнения»), и также падение производительности.
3. Также как и с пунктом 2.

Но вообще в Hack это есть, и они даже добавили статический анализатор типов для strict режима, который висит как демон, и hhvm просто обращается к нему: есть ошибки? нет, значит пусть приложение работает, если что в любой момент можно Exception выкинуть. И это дает реальный прирост производительности, потому что strict файлы отлично проверены как в Java. К примеру:
<?hh //strict
class User {
    protected int $id;
    public function getId():int {
        return $this->id;
    }
}

class UserManager {
    public function getIdentifier(User $user):int {
        return $user->getId();
    }
}


Сразу выкинет ошибки:
1. protected int $id — не задается в конструкторе и не имеет значение по умолчанию, поэтому нужно пометить как nullable:
protected ?int $id;

2. метод getId — может возвращать null, нужно пометить что он nullable, то-есть:
public function getId():?int{}

3. Выход из getIdentifier() может иметь null, нужно пометить.

И он очень хорошо просматривает то, какие типы должны использоваться, он в strict режиме запрещает использовать обычные массивы, рекомендует использовать Map, Vector, etc в указанием типа. И большинство ошибок сразу же всплывают во время сохранения файла.
Всего голосов 1: ↑1 и ↓0+1
Считаю не совсем правильным сравнивать типизацию в hack и php: в первом это необходимость, во втором — дополнение.
А что касается rfc, никто пока не знает и до конца не понимает, в каком направлении всё это будет развиваться. Надо сначала поиграться с тем, что есть, потом будут какие-то изменения, основанные на практическом применении
Всего голосов 2: ↑2 и ↓0+2
Я так смотрю, то о чем я писал про phar ещё в 2012, а использовал даже раньше начало доходить даже до Symfony. Может, вам сделать ещё раздел в дайджесте типа «habrahabr PHP flashback»?)
Всего голосов 1: ↑1 и ↓0+1
Docker это да, тоже пользуюсь.
Там немного иначе, Silex как фреймворк подключается, я же больше об альтернативе zip, когда файл имеет какой-то графический или консольный интерфейс, и используется не в виде подключаемого phar, а позволяет развернуть сконфигурированное приложение готовое к работе. Вот опять банально если бы WP вместо zip предлагал скачать phar.
Комментарий пока не оценивали0
в 2013-ом фабьен писал how-to как паковать приложения в phar. Но помниться мне были опосения что толку от этого не так много. Еще раньше в твиттере была дискуссия на эту тему, что мол phar не ок. Да и преимуществ это перед тем же zip/tar никаких не дает.
Всего голосов 1: ↑1 и ↓0+1
НЛО прилетело и опубликовало эту надпись здесь
>> function foo(int $abc): int

эмм… значения вида '123' пройдут или фатал эррор вызовут?
Комментарий пока не оценивали0
В нестрогом режиме (по дефолту) пройдут
Комментарий пока не оценивали0
По дефолту работает каст типов. Если может привести типы без потери — все хорошо. Скажем если у вас будет строка '12 monkeys' то вылетит варнинг (или нотис).
Всего голосов 2: ↑2 и ↓0+2
Спасибо, прочитал с удовольствием. С нетерпением жду php7!
Всего голосов 1: ↑1 и ↓0+1
Scalar Type Hints — Будет интересно!
Комментарий пока не оценивали0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Ваш аккаунт

Разделы

Информация

Услуги

Техническая поддержка
© 2006–2024, Habr