Дайджест интересных новостей и материалов из мира PHP за последние две недели №23 (29.07.2013 — 11.08.2013)

[AndryX]

помощь сторонних контрибьюторов ограничена ввиду сложности языка C, на котором написан фреймворк. Именно поэтому было решено разработать свой собственный язык, нечто среднее между PHP и С

Мда. А контрибьютеров на языке, который нигде больше не используется, кроме как в этом фреймворке будет больше? Весьма странное решение, PHP программисту лучше выучить С и получить глубокие знания, чем выучить Zephyr, который, по большому счёту, никому не нужен. В итоге получаем подобие vendor-lock'a, что не есть хорошо. А ограниченное количество документации (по сравнению с тем же С) лишь увеличивает порог вхождения, как бы похож на PHP он не был.

[voidMan]

Мне кажется никто не заставляет писать на Zephyr, можете на С — пишите на С

[mekegi]

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

Создав «еще один язык», они сильно снизят популярность своего детища. Ну и судя по их логике «предотвратят трудности».
На выходе будет очень узкое, редко используемое — никому не нужное нечто.

[AndryX]

Тоесть теперь контрибьюторы нужны и для того, чтобы поддерживать ядро на С, и для того, чтобы обслуживать развитие языка? Ну да, сразу «упростили», в два раза.

[Casus]

Так же подумал. Но посмотрев на код, который понятен без доков, и на цели Zephir — уже не так скептичен. Думаю это более интересная альтернатива hiphop и т.д.

[Casus]

Ну для начала в Go нет OOP. Да и цели у Go и Zephir весьма разные. На мой взгляд сравнение неуместно.

[DeusModus]

Согласен.
Go решает конкретные задачи системных и не очень программистов.
Зефир же будет погребен скорее всего еще раньше чем доберется до беты.

[Casus]

Как я понял из описания Zephir, это модуль для PHP, построенный на Zend движке, с целью упростить написание модулей для PHP. Например Phalcon, ну или создать свой модуль с целью ускорить нагруженный участок PHP кода.

Куда, в этом описании, вы хотите вставить Go?

Предвидя ответ в виде, «Заменить PHP на Go», отвечу что был бы за, но в большинстве случаев это не возможно.

[DeusModus]

Я не еавангелист го. Есть задачи в моей работе для php, есть для node.js, есть для го. Фалкон я с самого начала не понял, теперь еще и зефир какой-то.
Вы пытаетесь приписать моему комменту то, чего он не содержит :)

[Casus]

Извините, ответ был в ветке Zephir vs Go, вот и изтрактовал неверно.

[Casus]

Банальный пример: уже есть проект на PHP, не маленький. Кусок кода где парсится стринговый ответ работает медленно.

Варианты решения:
1. Переписать проект на Go/Scala/C/C++
2. Переписать проект под HipHop, kPHP
3. Вынести тормозящий кусок кода на Go/Scala/C/C++, запустить как daemon и общаться с ним по сокетам
4. Написать на C PHP extension.
5. Написать на Zephir PHP extension.
6. предложите своё решение!?

Что выберете?

Мы, ввиду невозможности первого варианта, сейчас решаем с помощью 3 и 4. Чаще 3, ибо 4 никто не хочет заниматься. И вариант с Zephir, отнюдь, не плохо бы смотрелся вместо 3 и 4.

[evnuh]

Чувствуется, пойдет теперь мода на интерпретацию / компиляцию PHP. В виде фреймворков, серверов, расширений и всего прочего.

[LastDragon]

RFC: Constructor argument promotion — Предложение от одного из разработчиков HipHop VM из Facebook, суть которого довольно проста: предлагается для аргументов, передаваемых в конструктор класса, автоматически создавать соответствующие свойства класса и присваивать им переданные значения.

Бредовое предложение :(

[Andre_487]

Похоже на Register Globals 2.0

[Casus]

Не поддерживаю Ваш скептицизм, посмотрите на Scala — синтаксис языка на порядок выше PHP, там как раз присутствует этот сахар. Вот тут пример класов и конструкторов в Scala.

[Andre_487]

Лично мне не по душе неявные присвоения. Сахар для присвоения аргументов конструктора свойствам — хорошая штука, но лучше, чтобы это было результатом явного вызова, например, как в C++:

class Foo 
{
    public:
        Foo(int bar) : _bar(bar) {
        }
    private:
        _bar:int;
}

[maximw]

Поддерживаю. Меньше магии = лучше.

[LastDragon]

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

Впрочем, смысла обсуждать, ИМХО, нет, т.к. реализация этого RFC полностью ломает обратную совместимость => реализован он не будет.

[chEbba]

Вы рфц точно читали? видимость задается, обратная совместимость не ломается

[LastDragon]

Честно говоря нет, т.к. идея все равно бредовая, но сейчас прочитал, поэтолу

видимость задается

Соглашусь.

обратная совместимость не ломается

Не соглашусь, см например пример в п6, и вопросы:

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

[LastDragon]

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

class Car { public function __construct(public $make, protected $doors, $model = 'unknown') { } }

М… возможно, не всё так бредово как казалось…

[Casus]

Конструкторы должны инициализировать объект, и не должны содержать логику. В Вашем примере, возможно, нужно использовать Build патерн.

[LastDragon]

Выносить логику в отдельный метод только ради того чтобы очистить конструктор от пары if-ов это ООП ради ООП.

[SamDark]

Ещё вышел Yii 1.1.14: habrahabr.ru/post/189820/

[pronskiy]

Да да, но чуть позже чем публиковался дайджест, поэтому еще включу в следующий выпуск