Comments 31
UFO just landed and posted this here
помощь сторонних контрибьюторов ограничена ввиду сложности языка C, на котором написан фреймворк. Именно поэтому было решено разработать свой собственный язык, нечто среднее между PHP и С
Мда. А контрибьютеров на языке, который нигде больше не используется, кроме как в этом фреймворке будет больше? Весьма странное решение, PHP программисту лучше выучить С и получить глубокие знания, чем выучить Zephyr, который, по большому счёту, никому не нужен. В итоге получаем подобие vendor-lock'a, что не есть хорошо. А ограниченное количество документации (по сравнению с тем же С) лишь увеличивает порог вхождения, как бы похож на PHP он не был.
+9
Мне кажется никто не заставляет писать на Zephyr, можете на С — пишите на С
+2
UFO just landed and posted this here
Тоесть теперь контрибьюторы нужны и для того, чтобы поддерживать ядро на С, и для того, чтобы обслуживать развитие языка? Ну да, сразу «упростили», в два раза.
+3
Так же подумал. Но посмотрев на код, который понятен без доков, и на цели Zephir — уже не так скептичен. Думаю это более интересная альтернатива hiphop и т.д.
0
Ну для начала в Go нет OOP. Да и цели у Go и Zephir весьма разные. На мой взгляд сравнение неуместно.
0
Согласен.
Go решает конкретные задачи системных и не очень программистов.
Зефир же будет погребен скорее всего еще раньше чем доберется до беты.
Go решает конкретные задачи системных и не очень программистов.
Зефир же будет погребен скорее всего еще раньше чем доберется до беты.
+2
Как я понял из описания Zephir, это модуль для PHP, построенный на Zend движке, с целью упростить написание модулей для PHP. Например Phalcon, ну или создать свой модуль с целью ускорить нагруженный участок PHP кода.
Куда, в этом описании, вы хотите вставить Go?
Предвидя ответ в виде, «Заменить PHP на Go», отвечу что был бы за, но в большинстве случаев это не возможно.
Куда, в этом описании, вы хотите вставить Go?
Предвидя ответ в виде, «Заменить PHP на Go», отвечу что был бы за, но в большинстве случаев это не возможно.
0
Я не еавангелист го. Есть задачи в моей работе для php, есть для node.js, есть для го. Фалкон я с самого начала не понял, теперь еще и зефир какой-то.
Вы пытаетесь приписать моему комменту то, чего он не содержит :)
Вы пытаетесь приписать моему комменту то, чего он не содержит :)
0
UFO just landed and posted this here
Банальный пример: уже есть проект на 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.
Варианты решения:
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.
0
UFO just landed and posted this here
Чувствуется, пойдет теперь мода на интерпретацию / компиляцию PHP. В виде фреймворков, серверов, расширений и всего прочего.
+3
RFC: Constructor argument promotion — Предложение от одного из разработчиков HipHop VM из Facebook, суть которого довольно проста: предлагается для аргументов, передаваемых в конструктор класса, автоматически создавать соответствующие свойства класса и присваивать им переданные значения.
Бредовое предложение :(
0
Похоже на Register Globals 2.0
0
Лично мне не по душе неявные присвоения. Сахар для присвоения аргументов конструктора свойствам — хорошая штука, но лучше, чтобы это было результатом явного вызова, например, как в C++:
class Foo
{
public:
Foo(int bar) : _bar(bar) {
}
private:
_bar:int;
}
+1
Проблемы возникают когда выяснятся что передаваемые в конструктор объекты нужны только для создания экземпляра — зачем тратить ресурсы на хранение этих бесполезных объектов? Как задать область видимости этих свойств? и т.д.
Впрочем, смысла обсуждать, ИМХО, нет, т.к. реализация этого RFC полностью ломает обратную совместимость => реализован он не будет.
Впрочем, смысла обсуждать, ИМХО, нет, т.к. реализация этого RFC полностью ломает обратную совместимость => реализован он не будет.
-1
Вы рфц точно читали? видимость задается, обратная совместимость не ломается
0
Честно говоря нет, т.к. идея все равно бредовая, но сейчас прочитал, поэтолу
Соглашусь.
Не соглашусь, см например пример в п6, и вопросы:
1) Что будет если это магическое свойство? (я так понимаю всё сломается? т.к. будет добавлено обычное поле класса, которое перекроет магической свойство)
2) Что будет если это свойство есть в трайте? (похоже фатальная ошибка о невозможности переопределить свойства класса свойством из трайта?)
видимость задается
Соглашусь.
обратная совместимость не ломается
Не соглашусь, см например пример в п6, и вопросы:
1) Что будет если это магическое свойство? (я так понимаю всё сломается? т.к. будет добавлено обычное поле класса, которое перекроет магической свойство)
2) Что будет если это свойство есть в трайте? (похоже фатальная ошибка о невозможности переопределить свойства класса свойством из трайта?)
0
Конструкторы должны инициализировать объект, и не должны содержать логику. В Вашем примере, возможно, нужно использовать Build патерн.
0
Ещё вышел Yii 1.1.14: habrahabr.ru/post/189820/
0
Sign up to leave a comment.
Дайджест интересных новостей и материалов из мира PHP за последние две недели №23 (29.07.2013 — 11.08.2013)