Isn't this the same as splicing, ngResource, and preserving references?

[ProLoser]

I get the feeling this syntax is sort of a convoluted way of simply sharing a state / reference across services. Nothing stops people from simulating ngResource by simply doing the following:

list: () ->
  data = []
  $http.get().then (results) ->
    data.push.apply(data, results)
  return data
read: (id) ->
  data = {}
  $http.get().then (results) ->
    angular.extend(data, results)
  return data

You can additionally set a property of a service to be the data container, and in your controller just attach the property to the scope:

myApp.factory('projects', ($http) ->
  return {
    data: {}
    find: () ->
      $http.get().then (response) ->
        angular.extend(this.data, response)
  }

myApp.controller('projctrl', ($scope, projects) ->
  $scope.projects = projects.data

I find this a lot more intuitive and far less verbose. I don't have to remember an additional layer of methods and api and can always understand what's going on with my data.

[mbertolacci]

Hi Proloser,

Thanks for the feedback!

It's similar to that syntax, but it allows the service to use watchers so they can be notified when something changes on their scope. That way, the two-way data binding reaches back into the service without the controller needing to trigger a function on the service whenever anything changes.

I agree it's more verbose than what you suggested. For me it was more about creating a syntax that made it easy for multiple developers on a system to understand, so that they don't have to do complex accounting in their head of questions like which objects on the scope are promises and which are data (and hence which are safe to overwrite and which are not.)

But it's a bit of an experiment and I suspect there's a nicer syntax or set of conventions lurking elsewhere that I haven't stumbled across yet :)

[ProLoser]

How is $serviceScope different from $rootScope?