Pull to refresh

Comments 14

Представляю, сколько людей прочитав эту статью подумало: «О, отличные примеры для собеседований!». Ведь это так здорово, спрашивать программиста как отработает код, за который в реальном проекте надо сразу увольнять. А так — повод потешить свое самолюбие, и посмотреть как люди с 10+ летним опытом не знают «элементарных вещей».
Данный материал содержит не очень очевидные возможности языка. Обычно к ним относятся с насмешкой: «опять этот г… код», «повод потешить свое самолюбие» и т.д Тут нет действительно ничего нового для меня.
Однако именно из таких находок появляются иногда интересные технические решения и библиотеки. Такие как ocramius/proxy-manager, goaop/framework и другие. Поэтому иногда приходится покопаться в мусоре чтобы отыскать тот самый бриллиант что там лежит.

Моя команда с увлечением решала нестандартные задачки, а теперь это высококвалифицированные специалисты, работающие в крупных известных компаниях.

Само-собой, не надо спрашивать такие вопросы на собеседованиях ) Но вот заинтересоваться в примерах самому и попробовать сделать что-то свое интересное — всегда можно. Главное — не останавливаться на достигнутом.

А что касательно самой презентации и видео насчет магии — это да, здесь был маркетинговый аспект, нацеленный на подачу именно во время конференции, поэтому прошу прощения за некоторое зазнайство — это было нужно чтобы достичь правильной подачи доклада.

Отличная статья. Спасибо, прочёл с удовольствием


Меня заинтересовал ваш framework. Допустим, у меня есть код:


/**
 * @Before("execution(public UserService->*(*))")
 * @param MethodInvocation $invocation
 * 
 * @throws AccessDeniedException
 */
public function checkPermission(MethodInvocation $invocation) {
    if(!$this->security->isGranted('ROLE_USER')) {
        throw new AccessDeniedException();
    }

    // ...
}

… который мне нужно применить не только к одному конкретному классу (в данном случае UserService), а сразу к группе файлов или директории/пространству имён. Это возможно?

Да, конечно возможно. Используйте двойную звездочку для указания любого неймспейса и одинарную для указания компонента. Например, execution(public Acme\**\Service*->*(*)) — будет совпадать со всеми вызовами публичных методов классов из неймспейса Acme на любом уровне вложенности и имя которых начинается с префикса Service.

Дополнительные примеры можно глянуть из теста: PointcutParserTest фреймворка.
UFO just landed and posted this here
Да, рядом с указанием вызова методов execution() нужно будет дописать еще && within(YourInterfaceName+) — это сматчится со всеми вызовами методов определенных в классах, реализующих заданный интерфейс YourInterfaceName.

Смотрите примеры грамматики поинткатов в тесте )

Здорово! Большое спасибо за разъяснение

Спасибо. Очень пригодится, если придется разбирать чей-то легаси-код с подобными трюками.

Далеко не факт, что такие трюки будут именно в легаси. Тот же биндинг замыканий я часто использую для гидрации/дегидрации объектов в ORM-like задачах. Да и для тестов бывает удобно, пускай они и хрупкими получаются.

Да, PHP пропитан магией! Главное не превратить свой код в diablo. Где в конце придется победить главного босса...

У меня синдром самозванца чуть не начался после прочтения, особенно про AOP :)
А где-то полгода назад я впервые услышал о мутационном тестировании php на конференции.
При этом всем я уже довольно приличное время в веб разработке.
Видимо веб такая штука, когда в принципе появляется много чего каждый год, но все это решает часто не существующие проблемы, либо уже решённые. В итоге ты учишь много чего, а сделать можешь в основном то, что и 5-8 лет назад.

У меня синдром самозванца чуть не начался после прочтения, особенно про AOP :)
А где-то полгода назад я впервые услышал о мутационном тестировании php на конференции.
При этом всем я уже довольно приличное время в веб разработке.

Видимо веб такая штука, когда в принципе появляется много чего каждый год,

«Mutation testing was originally proposed by Richard Lipton as a student in 1971» © wiki. И веб тут не причём.
Пора бы уже перестать пиарить миф о том что в разработке всё кардинально меняется каждый год. Большинство идей тянутся из прошлого века.

но все это решает часто не существующие проблемы, либо уже решённые

Не существующие у вас или не существующие ни у кого в индустрии?
Если первое то не показатель, а если второе то сильно громкое заявление.

А случаи решения несуществующих проблем существуют — да, но относятся к конкретным проектам. Design-by-buzzword, то есть попытка применять архитектурные ограничения без чёткого понимания их полезности процветает в индустрии.
когда в принципе появляется много чего каждый год

https://github.com/goaop/framework/releases/tag/1.0.0 — 2016, а вообще проекту лет 6


В итоге ты учишь много чего, а сделать можешь в основном то, что и 5-8 лет назад.

Подразумевается, что учишь для того, чтобы сделать это эффективней чем до начала этой учёбы.

Sign up to leave a comment.