This change was discussed: https://github.com/angular/angular.js/pull/4509

It is also clear from the discussion that there are dissenting opinions -- we are constantly iterating and welcome issues and pull requests to make features work even better. The best way to influence AngularJS is to send a pull request.

You are right it was. But most people do not track all issues of all projects they depend on. While I'd love to do that, there's simply not much time.

I belive this should have been in an earlier RC or Beta. This way, more people would have tested ot, ir got a chance to read changelog (I follow the blog and check each beta release). If that window was missed, it should have gone for the next major release.

What I see is that Google announced AngularDart (http://news.dartlang.org/2013/11/angular-announces-angularda...). Dart has _ prefix for private fields. Then AngularJS team goes ahead and forces the same on the JS implementation.

Seems that there is always some political reason to mess with things at Google.

Many other languages and projects use underscores to indicate private properties, in particular Google's Closure. I also have no idea how standardizing on _ in names meaning private would do anything to push Dart in some hidden, evil agenda.

I think the change is reasonable, limiting AngularJS' expression to leak less information into the templates is a good idea IMHO, as described in particular with the new controller syntax.

Disclosure: I work at Google, but I have not been involved in this discussion at all.

I pay pretty close attention to the issues in the repo, but I apparently missed this. I am also a regular in #angularjs, and never seen it discussed there either, so while the discussion was public, I think it caught almost everyone by surprise.

I'm running into a similar issue and fairly new to angular. In fact, the tutorial I followed even set up the server calls to use the _id field when looking at a specific model (ie leagues/{{ league._id }} ). What's the proper way to go about fixing this?

You can always create functions that refer to the private element:

MyObject.prototype.id = function(){return this._id;};

Which gives you: leagues/{{ league.id() }}

so what the point of introducing a "private" access modifier that doesnt exist in javascript since one can still access privates? looks like pure politics within google.

A breaking change like that shoved at the latest minute? you bet it is.

> shoved at the latest minute

The pull request was opened 3 weeks ago with plenty of discussion.

3 weeks of discussion for a breaking change is "last minute" in my book

why didnt you think about having this feature optional? class based controllers are optional yet,because of them you introduce a feature that affect function based controllers ?

> why didnt you think about having this feature optional?

Opt-in security features aren't very useful.

> class based controllers are optional yet,because of them you introduce a feature that affect function based controllers ?

That's how competing constraints work out sometimes.

We're always looking to improve though. The code is open source, so feel free to submit a PR or fork it if you disagree. :)

Don't use 1.2.0 until it's reverted or write a getter.

Never send DB output directly to frontend, send object, filled by only necessary values from DB output. Otherwise you'll meet security issues and these "_" prefixes will be smalles part of your problems.

And how are you supposed to do that using Mongolab, MongoHQ or Firebase?

you seem to be taking as a given that those are acceptable things to do.

And you seem to be implying that they're not okay to do. Feel free to substantiate your opinion.

I do that. It's not about sending them directly. It's the underlying field name. I just keep _id fields as _id fields when I prepare data for output.