Комментарии 16
Не понимаю, зачем описывать все типичные методы в Application\Entity\Book, если все это можно реализовать через __call метод, а описать только сложные, например:
а для автокомплита написать PHPDoc над классом:
Это лично мое видение всего этого, а так, Саня, молодец, старался )
public function getFullName(){
return $this->getAuthor() . ' : ' . $this->getTitle();
}
а для автокомплита написать PHPDoc над классом:
namespace Application\Entity;
use Zf2ActiveRecord\AbstractActiveRecord;
/**
*@method int getId()
*@method Book setId($id)
*@method string getAuthor()
*@method Book setAuthor($author)
* etc.
* ...
*/
class Book extends AbstractActiveRecord
{
/**
* @var int
*/
protected $id = null;
/**
* @var string
*/
protected $author = null;
/**
* @var string
*/
protected $title = null;
}
Это лично мое видение всего этого, а так, Саня, молодец, старался )
Вообще-то, Ваня, можно и не писать типичные методы, а сделать $entity->getArrayCopy(), это просто пример ;)
Работать будет через __call а IDE видеть через PHPDoc — и ради чего?
Ради скорости? Тогда лучше на каждое свойство геттре/сеттер.
Ради автодополнения в IDE? Не знаю как ваша IDE, а Netbeans генерит геттеры/сеттеры автоматически. А вот этот PHPDoc я должен руками писать?
Ради скорости? Тогда лучше на каждое свойство геттре/сеттер.
Ради автодополнения в IDE? Не знаю как ваша IDE, а Netbeans генерит геттеры/сеттеры автоматически. А вот этот PHPDoc я должен руками писать?
Мне показалось это более чем очевидным, но так и быть — поясню:
1. Отсутствие PHPDoc ИМХО — моветон.
2. Определять в классе методы, которые можно и не определять, это уже из разряда индусского кода, когда платят за количество строк.
3. Как раз ради скорости! Количество кода в файле, увеличивает время парсинга ( но не стоит пренебрегать coding style).
4. PHPDoc моя IDE тоже умеет генерировать, но уметь его писать и понимать — это несомненный плюс.
и на конец:
5. «PHPDoc я должен руками писать?» — интересно, чем Вы обычно пишите код?)
1. Отсутствие PHPDoc ИМХО — моветон.
2. Определять в классе методы, которые можно и не определять, это уже из разряда индусского кода, когда платят за количество строк.
3. Как раз ради скорости! Количество кода в файле, увеличивает время парсинга ( но не стоит пренебрегать coding style).
4. PHPDoc моя IDE тоже умеет генерировать, но уметь его писать и понимать — это несомненный плюс.
и на конец:
5. «PHPDoc я должен руками писать?» — интересно, чем Вы обычно пишите код?)
1. Отсутствие PHPDoc ИМХО — моветон.
Это не так
2. Определять в классе методы, которые можно и не определять, это уже из разряда индусского кода, когда платят за количество строк.
Т.е. отсутствие PHPDoc'a — моветон, а отсутствие кода — ок?!
3. Как раз ради скорости! Количество кода в файле, увеличивает время парсинга ( но не стоит пренебрегать coding style).
При использовании opcode кэшера мы упраздняем лексический и синтаксический разбор файла и сразу переходит к байт-коду. А вот там как раз и используется магия __call, которую интерпритатор исполняет дольше.
5. «PHPDoc я должен руками писать?» — интересно, чем Вы обычно пишите код?)
Стараюсь максимально автоматизировать используя IDE
1. Советую перечитать Стандарт кодирования на PHP в Zend Framework'е и обратить внимание на слова «MUST» возле слова «PHPDocumentor».
2. Ответьте себе на вопрос, зачем нужна __call функция. Код ведь в ней присутствует.
3. Интерпретатор это не шайтан-машина, магии там нет. Прочитайте про Zend Engine 2.
5. __call метод как раз уменьшает писание кода и автоматизирует процесс.
Я так понимаю, это «диалог глухого со слепым». Удачи Вам в Вашем творчестве.
2. Ответьте себе на вопрос, зачем нужна __call функция. Код ведь в ней присутствует.
3. Интерпретатор это не шайтан-машина, магии там нет. Прочитайте про Zend Engine 2.
5. __call метод как раз уменьшает писание кода и автоматизирует процесс.
Я так понимаю, это «диалог глухого со слепым». Удачи Вам в Вашем творчестве.
Где в Стандарт кодирования на PHP в Zend Framework'е сказано, что каждый (публичный) метод должен иметь PHPDocumentor?
Ну, и если на то пошло, то вот вам стандарт PSR-2-coding-style-guide Нигде не вижу обязательное использрвание PHPDocumentor'а в коде.
Ну, и если на то пошло, то вот вам стандарт PSR-2-coding-style-guide Нигде не вижу обязательное использрвание PHPDocumentor'а в коде.
1. Отсутствие PHPDoc ИМХО — моветон.
надо знать меру, с таким успехом пхпдока будет больше чем кода ;)
2. Определять в классе методы, которые можно и не определять, это уже из разряда индусского кода, когда платят за количество строк.
не соглашусь, самые важные кретерии качества кода — это его дальнейшее сопровождение и переносимость, тут магия получает минус
3. Как раз ради скорости! Количество кода в файле, увеличивает время парсинга ( но не стоит пренебрегать coding style).
о скорости в данном случае говорить не стоит, но я всегда думал, что рантаймовая магия медленнее… не?)
4. PHPDoc моя IDE тоже умеет генерировать, но уметь его писать и понимать — это несомненный плюс.
пхпдок — мета-описание мета-конструкций да еще и интерпретируемого языка, тройное мета :)
Умник, ты тоже иди почитай Coding Style =)
Пулреквесты принимаешь?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
ZF2 ActiveRecord Module