Да, я смотрел. Но это не объясняет почему нет возможности привязывать интерфейс к трейтам. А прописывать для каждого трейта его же интерфейс, это немного напряжно: нужно знать какой интерфейс он реализует, и потом знать как это в коде проверить.
Короче, пока что это всё не принципиально. Просто трейты + интерфейсы были бы отличной независимой связкой кода с огромными возможностями.
trait Timestampable implements Timestampable {
function setCreatedAt();
function setUpdatedAt();
}
Пусть использование интерфейса будет опционально. Но было бы неплохо, если бы он был.
Просто хотелось бы адекватно реагировать в зависимости от того какой модуль подгружен.
Но. По интерфейсу несомненно удобнее. По сути, интерфейсы и трейты решают одну и ту же проблему, странно, что им не дано работать вместе.
Кроме того, существенное ограничение: This function returns an array with the names of the traits that the given class uses. This does however not include any traits used by a parent class.
Трейты это не миксины. Это легализированный копипаст =)
Что жаль, что трейты не связанные с интерфейсом. Т.е. нельзя проверить, например, включен ли в класс тот или иной трейт по интерфейсу. А это было бы очень даже неплохо.
Да, работал с ним. После него попробовал Sony Vegas — такая простая удобная штука…
Там нет многих функций (типа наложить текст или эффект какой). Есть и удобные вещи.
Может когда заматерею вернусь на Lightworks
Со всем согласен. Не понимаю, зачем сразу продавать всю компанию? Интеграция с фейсбуком будет выигрыш и скачок в разработке (сколько мы уже 12ку ждем?)
Но я не хочу, чтобы опера становилась фейсбуком. Это должна быть отдельная компания со своей стратегией. А не часть мордобука. Если Оперу купит с потрохами фейсбук — уйду нахреном.
Но всё-таки Опера это не та компания, которую можно купить за 5-летние опционы…
Вам привычный assert, ибо вы уже работали с тестами. Ничего не имею против такой конструкции, но целью было писать такой код, чтобы я мог даже заказчику и тестеру его показывать и говорить: ничо не знаю, вот вчера тест всё гонял, всё работало :)
Альтернативный вариант синтаксиса это PHPUnit + Mink. Там всё привычно.
Как клиенту мне пофиг какие классы используются, лишь бы сайт работал =)
Я конечно согласен, что приватные методы тестировать зачастую не стоит, ибо они не отвечают за связь между юнитами, но нельзя же говорить, что их никогда тестировать не надо. Ситуации бывают разные.
Всякие случаи бывают.
Если там, допустим, какая-то сложная логика, которую лучше отдельно протестировать.
Ну или если, неочевидно когда именно этот метод будет вызван публичным.
Класс должен реализовать интерфейс. Интерфейс передан с трейтом командой use. Всё. В чем конфликт?
Короче, пока что это всё не принципиально. Просто трейты + интерфейсы были бы отличной независимой связкой кода с огромными возможностями.
Пусть использование интерфейса будет опционально. Но было бы неплохо, если бы он был.
Просто хотелось бы адекватно реагировать в зависимости от того какой модуль подгружен.
Но. По интерфейсу несомненно удобнее. По сути, интерфейсы и трейты решают одну и ту же проблему, странно, что им не дано работать вместе.
Кроме того, существенное ограничение: This function returns an array with the names of the traits that the given class uses. This does however not include any traits used by a parent class.
Что жаль, что трейты не связанные с интерфейсом. Т.е. нельзя проверить, например, включен ли в класс тот или иной трейт по интерфейсу. А это было бы очень даже неплохо.
Впрочем, никто не спорит, что трейты это вкусняшка.
Там нет многих функций (типа наложить текст или эффект какой). Есть и удобные вещи.
Может когда заматерею вернусь на Lightworks
Но я не хочу, чтобы опера становилась фейсбуком. Это должна быть отдельная компания со своей стратегией. А не часть мордобука. Если Оперу купит с потрохами фейсбук — уйду нахр
еном.Но всё-таки Опера это не та компания, которую можно купить за 5-летние опционы…
Что странно. Так сколько их всё-таки?
Вам привычный assert, ибо вы уже работали с тестами. Ничего не имею против такой конструкции, но целью было писать такой код, чтобы я мог даже заказчику и тестеру его показывать и говорить: ничо не знаю, вот вчера тест всё гонял, всё работало :)
Альтернативный вариант синтаксиса это PHPUnit + Mink. Там всё привычно.
В любом случае, объективные абстракции, которые начинаются со слов «зис ассерт» намного сложнее в понимании, даже с каментами, чем «ай си» =)
Но вцелом согласен.
Я конечно согласен, что приватные методы тестировать зачастую не стоит, ибо они не отвечают за связь между юнитами, но нельзя же говорить, что их никогда тестировать не надо. Ситуации бывают разные.
Если там, допустим, какая-то сложная логика, которую лучше отдельно протестировать.
Ну или если, неочевидно когда именно этот метод будет вызван публичным.