из $Scope в функцию

[DjDiablo]

На данный момент в портируемом проекте я использую один контроллер на страницу, всё остальное реализовано через директивы, все взаимосвязи указаны в атрибутах директив.

В твоём случае доступ к scope родителя можно получить через $scope.$parent если не ошибаюсь, после изменения parent можно опубликовать изменения при помощи $scope.$parent.$apply()

[Shitbox2]

Подскажите как можно сделать из Скопа - функцию чтобы внутри нее можно было вызывать другие Скопы и с ними работать.

Вот так делать не стоит. Поначалу тоже что-то подобное мутил. В итоге намухлевал с иерархией областей видимости, пробовал перемещаться по областям через свойства $parent, lastChild и т.п. И получил кучу проблем. Тут самое верное решение разделять данные через сервис, пусть даже его придется 100500 раз указывать в зависимостях.

$scope.paginator.setPages($scope.items.length);

Такого быть не должно. Нужно как-то так:

myService.paginator.setPages(items.length);

$scope только для передачи данных в вид и такое его использование рано или поздно приведет к проблемам.

Также можно использовать механизм событий
$emit('MyEvent') и $broadcast('MyEvent')

И писать как-то так

$scope.$on('MyEvent', function() {
    $scope.count++;
  });

Ну или просто передавать данные через $rootScope и подписываться на них через $watch

[DjDiablo]

Подскажите как можно сделать из Скопа - функцию чтобы внутри нее можно было вызывать другие Скопы и с ними работать.

Присоеденяюсь к Shitbox. Сделать так можно но делать этого не стоит.

Нужно стремится по возможности к слабому связыванию компонентов. Это аксиома проектирования в любом языке, любом фреймворке, не зависимо от того какую программу вы пишете.

Из красивых решений это атрибуты директив, либо события. Атрибуты деректив это в каком то смысле шлюзы компонентов, и через такие шлюзы можно относительно безопасно состыковывать компоненты UI между собой.

Можно иметь общие данные для обсолютно независимых котролов и деректив, но придётся их хранить в сервисе и подключать сервис там где нужен доступ к этим данным. Вместе с данными в сервисе желательно хранить и методы обработки этих данных, такие методы можно будет вызывать из любого контрола где используется этот сервис (в 7ом посте писал об этом). Сделать сервис частью scope тоже труда не составляет.

Сервис конечно не обеспечивает синхронизацию данных между различными компонентами, иными словами если один контроллер изменит данные в сервисе, то другой контроллер об этом изменении не узнает. Если нужна синхронизация то в качестве решения может проканать rootScope. Но так как обьект глобальный то злоупотреблять им не стоит, если всё пихать в rootScope то при изменении одних данных будет дёргаться слишком много лишних обработчиков watch. Довольно плохо если объекты и свойства в rootScope будут создаваться не централизованно а размазано по различным контроллерам, такое приложение будет сложно понимать.

Из любопытных идей мне на ум приходит создание сервиса со своим cобственным scope. Такой финт позволит сочетать преимущества сервиса, с возможностью синхронизации при изменении данных при этом избегая универсального глобального объекта $rootScope. Получится что то вроде "активной модели". Однако в angular потребности в подобных инструментах у меня пока не возникало.

Собрать же кучу скопов различных компонентов в одной функции это возможно худшее из всех возможных решений.

[MaximusFT]

Огромнейшее спасибо!
Буду переваривать информацию... так как скорее всего еще не до конца понял точку применения AngularJS.
От сюда возник вопрос, но уже в новой теме.