Черт, естественно оно работает, чего б ему не работать :) Вот только
Вся целостность приложения ломается
Как вы в таком случае намереваетесь налаживать какое-то взаимодействие между этими компонентами? И, главное, зачем так извращаться? Если приходиться это делать чтобы сократить количество watcher'ов, то тут проще вообще от data-binding'а в шаблонах избавиться, чем по инстансу приложения создавать на контрол. Про удачность апи это да.
А что это дает в сравнении со $scope.$new() с вызовом $digest на нем? В чайлдовых директивах и темплейтах все равно будет использоваться то что возвращает $injector сервис. Вся целостность приложения ломается. Либо я чего-то не понимаю.
я не знаю, что там происходит с Angular Light, но в обычном Angular'е, никаких дополнительных $rootScope на каждую директиву не создается. $rootScope это вообще сервис, который по определению синглтон в ангуляре. Isolated scope это другое. В производительности можно выиграть, если вызывать $digest на этом скоупе, вместо $apply ($rootScope.$digest). Но это может быть не всегда возможно.
Какой путаницы? Dependency Injection он и в Африке DI. Можно инжектить в конструктор, а можно в объект. С другой стороны, и Service Locator, и DI являются реализациями Dependency Inversion принципа (последняя буква solid). И вот тут уже путать не надо. DI, в отличае от Service Locator'а, как минимум позволяет а) абстрагироваться от контейнера б) отдать управление жизненым циклом объектов на аутсорс. Если и есть в этом мире антипаттерны, то это классический синглтон, и Service Locator.
2. объект в переменной как был ArrayList, так и останется. Что плохого в том что тип переменной это отражает? Если потом этот list возвращается как List или передается в функцию которая ждет интерфейс — ничего не изменится, наружу точно так же и будут торчать интерфейсы… Единственный случай, который в голову приходит, это если в эту же перменную надо будет позже положить другой объект, который не ArrayList, а List. Нууу, explicitly typed variables никто не отменял.
Для непосвященного человека выглядит круто, даже если там все на самом деле легко и неправильно :)
Но вывод, конечно, просто прелестен — может ли баг в программе вызывать переполнение памяти? Да, может, если потребление памяти (к примеру, вызванное багом в программе) превысит максимальный ее объем.
Ну так спорили же за обычный. Идеальных фреймворков вообще не бывает, посмотрим чего они там намудрят…
Как вы в таком случае намереваетесь налаживать какое-то взаимодействие между этими компонентами? И, главное, зачем так извращаться? Если приходиться это делать чтобы сократить количество watcher'ов, то тут проще вообще от data-binding'а в шаблонах избавиться, чем по инстансу приложения создавать на контрол. Про удачность апи это да.
Но вывод, конечно, просто прелестен — может ли баг в программе вызывать переполнение памяти? Да, может, если потребление памяти (к примеру, вызванное багом в программе) превысит максимальный ее объем.