В чем действительно нет смысла, так это в развитии данной темы (бессмысленность поста искать в том что код не везде будет работать, я повторюсь — я не представлял здесь какой-то библиотеки, которую можно где-то юзать, я представлял здесь идею внесения нетипичного для js синтаксиса).
Прочитайте еще раз тему топика и проследите как развивалась мысль. Я не признавал бессмысленность, я признал, что не сохранял контекст, т.к. без него код выглядел нагляднее, не нужно подменять слова.
В jQuery и dojo тоже есть АОП. Просто АОП нужно когда нужно, а когда не нужно… оно как бы и не нужно. как-то так (и не капитан вовсе). Знать все равно полезно, так хоть можно увидеть где применить можно
Полностью согласен, но для наглядности сделано (даже коменты добавил, и атрибут специальный, в котором можно полностью указать куда положить функцию надо)
Но ведь и статья не звучит как «АОП в JavaScript». Идея синтаксиса только важна, да и на крупном проекте тут применять нечего, изложена основания идея, не предложена никакая библиотека и тем более ссылок на сорсы.
Вообще по сути тут даже АОП звучит просто как контекст задачи, т.к. свелось все к эмуляции атрибутного синтаксиса, поэтому и ошибки вы видите те, которые возникнут при применении на вашем проекте, а для моей задачи их не возникнет. А при желании использовать эту идею передачу контекста можно и доработать
Но для обертки функции придется писать wrap(that, target, aspect); где-нибудь в коде (впринципе можно сразу перед функцией написать). А за то, что это хорошее решение я и не борюсь, просто псевдо-декларативный синтаксис выглядит заманчиво, это и хотел показать
Знает, просто изначально передавалось имя функции в дополнительном атрибуте, и объяление могло иметь вид, поэтому таким способом было проще(все объекты были доступны), но да… неправильно сделал
AOP(
[FunctionName("Something.protype.method")],
function something$method() {
...
}
);
Согласен с критикой…
По этому имени искать/создавать обеък- владельца метода было бы привильно. Спасибо
При разработке через TDD именно таких моментов избегают. Юнит тесты узконаправленны и проверяют отдельную реализацию, чтобы только что написанный код соответствовал требованиям.
Как правило, такие тесты запускаются «кусочками», т.е. для модулей и должны проходить быстро. А интеграционные обычно длятся долго и запускаются гораздо реже. (и о них тоже пишут, и не мало)
> и даже если оба модуля некорректны, но тесты их тандем проходит
Прочитайте еще раз тему топика и проследите как развивалась мысль. Я не признавал бессмысленность, я признал, что не сохранял контекст, т.к. без него код выглядел нагляднее, не нужно подменять слова.
Вообще по сути тут даже АОП звучит просто как контекст задачи, т.к. свелось все к эмуляции атрибутного синтаксиса, поэтому и ошибки вы видите те, которые возникнут при применении на вашем проекте, а для моей задачи их не возникнет. А при желании использовать эту идею передачу контекста можно и доработать
Согласен с критикой…
По этому имени искать/создавать обеък- владельца метода было бы привильно. Спасибо
При разработке через TDD именно таких моментов избегают. Юнит тесты узконаправленны и проверяют отдельную реализацию, чтобы только что написанный код соответствовал требованиям.
Как правило, такие тесты запускаются «кусочками», т.е. для модулей и должны проходить быстро. А интеграционные обычно длятся долго и запускаются гораздо реже. (и о них тоже пишут, и не мало)
> и даже если оба модуля некорректны, но тесты их тандем проходит
Это уже вопрос о корректности написанных тестов