То что всегда хочется сделать в первую очередь в форматировании вывода команд симфони — добавить кастомных методов и хукуов. Ибо использовать эти их XML теги для стандартных вещей крайне нерационально. Лучше добавить предустановленных методов вывода сразу с красивым форматированием.
Кстати, вы уже попробовали бету мобильной Opera для Андроида 2.3 и выше?
кстати, попробовал. Тормозит больше чем обычная опера, нет нормального Opera Link.
Может это особенность беты, но пока ничего хорошего в новой версии не увидел :(
То ли мне кажется, но впечатление, что вебкит на мобильном более тормознутый чем престо.
Да, прикольно. Спасибо за либу! Попробую по возможности.
Кстати, хотел узнать: будет ли документация на английском?
Я тут недавно апрувил вашу либу на Jster.net, и было б неплохо, чтобы не только русскоязычные пользователи могли ею воспользоваться.
Блин, это всё истинная правда. Тоже занимаюсь опен-сорс поректом Codeception. codeception.com
Была затронута тема неадекватных пользователей, создающих Issues, но больше всего меня бесят «гении». Которые приходят и начинают говорить: вот это лучше переименовать, тут сделать больше конфигцураций, добавить Dependency Injection, поменять структуру папок.
И вот спрашивается, ну зачем вам быть такими гениальными? Сделайте хотя бы один патч и я ваше мнение будет учитываться. Так нет, обижаются, когда их громадные простыни закрываются, обижаются, когда я трачу свое время обсуждая рациональносьт предложенных решений.
Поймите объяснить чуваку, сделавшего всё не по инструкции, намного проще, чем вести философские дискурсы с «гениями».
А вообще это клево, что у нас на Хабре так много опенсорс разработиков. Хотелось бы не терять связь и поддерживать друг друга.
В Symfony2 get типизирован под… вообщем никак он не типизирован. То же и в Pimple.
В чем собственно и печалька.
Потому я считаю, что так строить контейнеры нельзя.
Из всех вариантов я вижу 2:
— статически строить контейнер и дампить в файл. Но чтобы метода доступа к сервисам всегда были публичными.
— строить контейнер ручками.
with Service Locator is that it hides a class’ dependencies, causing run-time errors instead of compile-time errors, as well as making the code more difficult to maintain because it becomes unclear when you would be introducing a breaking change.
__get/__set работает одновременно для всего класса.
И это печально. Ибо один метод по сути ответственный за геттеры сеттеры всех полей.
А если мы хотим добавить какой-то кастомный геттер в одно поле, а другой в другое, — придется вешать много костылей на бедный __get.
Ну просто ваш DIC для меня принципиально ни чем не отличается от обоих DIC, что сделал Фабьен.
Чего бы лично мне хотелось от DIC: меньше всякой магии. Ибо такие контейнеры подобны фокусникам, что вытаскивают кролика из шляпы.
не понимаю в чем преимущество поддерживать такую конфигурацию, вместо того, чтобы все эти сервисы прописать вручную.
class DIC {
function getService1()
{
return new Service1();
}
function getService2()
{
return Serivce2($this->getService1());
}
}
Плюсы реализации: никакой магии, всегда знаем что в контейнере, никаких плясок с бубном вокруг конфигурации (почему оно незаинжектилось), можно явно удалять-добавлять сервисы.
Минусы: чуть сложнее реализовать LazyLoading и… Дописывайте в комментариях )
Вопрос скорее не в фичах, а в их реализациях.
Если бы самые крутые РНРшники, принимающие PSR, знали Си и могли хакать РНР как они захотят, то через 1-2 итерации мы получили бы Джаву. Ну и зачем?
То что сразу бросается в глаза — вывод секций
и строк с несколькими параметрами.
Всё это стоит упросить и сделать код более компактным )
А так идея и реализация очень прикольные. Спасибо
кстати, попробовал. Тормозит больше чем обычная опера, нет нормального Opera Link.
Может это особенность беты, но пока ничего хорошего в новой версии не увидел :(
То ли мне кажется, но впечатление, что вебкит на мобильном более тормознутый чем престо.
Это насчет альтернатив.
foundation.zurb.com
Кстати, хотел узнать: будет ли документация на английском?
Я тут недавно апрувил вашу либу на Jster.net, и было б неплохо, чтобы не только русскоязычные пользователи могли ею воспользоваться.
jster.net/library/backbone-js
по мере возможностей мы учтем пожелания.
да, джестер это не только каталог, а ещё и блог. По крайней мере, мы так пытаемся его развивать.
Кстати, судя по всему этот курс не совсем новый, на CodeSchool он давно.
Я вот вчера прошел на CodeSchool jQuery Air: Captain's Log. Понравилось.
Вообщем молодцы ребята, очень емко, лаконично.
Была затронута тема неадекватных пользователей, создающих Issues, но больше всего меня бесят «гении». Которые приходят и начинают говорить: вот это лучше переименовать, тут сделать больше конфигцураций, добавить Dependency Injection, поменять структуру папок.
И вот спрашивается, ну зачем вам быть такими гениальными? Сделайте хотя бы один патч и я ваше мнение будет учитываться. Так нет, обижаются, когда их громадные простыни закрываются, обижаются, когда я трачу свое время обсуждая рациональносьт предложенных решений.
Поймите объяснить чуваку, сделавшего всё не по инструкции, намного проще, чем вести философские дискурсы с «гениями».
А вообще это клево, что у нас на Хабре так много опенсорс разработиков. Хотелось бы не терять связь и поддерживать друг друга.
В чем собственно и печалька.
Потому я считаю, что так строить контейнеры нельзя.
Из всех вариантов я вижу 2:
— статически строить контейнер и дампить в файл. Но чтобы метода доступа к сервисам всегда были публичными.
— строить контейнер ручками.
И вот в этот момент get'а будет происходить магия и падение.
blog.ploeh.dk/2010/02/03/ServiceLocatorIsAnAntiPattern.aspx
DIC ничем не лучше.
Всё лучше чем по конфигурациям лазить.
И это печально. Ибо один метод по сути ответственный за геттеры сеттеры всех полей.
А если мы хотим добавить какой-то кастомный геттер в одно поле, а другой в другое, — придется вешать много костылей на бедный __get.
Чего бы лично мне хотелось от DIC: меньше всякой магии. Ибо такие контейнеры подобны фокусникам, что вытаскивают кролика из шляпы.
Плюсы реализации: никакой магии, всегда знаем что в контейнере, никаких плясок с бубном вокруг конфигурации (почему оно незаинжектилось), можно явно удалять-добавлять сервисы.
Минусы: чуть сложнее реализовать LazyLoading и… Дописывайте в комментариях )
Если бы самые крутые РНРшники, принимающие PSR, знали Си и могли хакать РНР как они захотят, то через 1-2 итерации мы получили бы Джаву. Ну и зачем?
Ну кроме авторизации через вконтакт и внутресайтовой авторизации.