Interpolation should call toString on objects

[ewinslow]

The string value is what is going to be used in the rendering of the information, but this doesn't seem to be respected.

http://plnkr.co/edit/ZLmiavC9lSlKj1b6cQJk?p=preview

For a real-world use-case: We'd like to return goog.Uri instances from our controller and have angular appropriately format them in the template, but it doesn't work -- it seems like the uri instances are compared by identity instead of string value (even though only string value will affect what the user sees), which I think was causing infinite loops. In the plunkr above I cannot get the right information to show up without manually stringifying first.

Right now our workaround is to call toString() or + "" manually within the controller, but this is just visual noise... it also is incentive to pass around strings instead of js objects, which I think would obscure the intent of the code.

[wesleycho]

I don't think Angular should do that - you would get some weird behavior happening if it did that on objects. For example, here is some of the undesired behavior one might get if this was supported:

var foo = {};
foo.toString() // yields '[object Object]'
{} + '' // yields 0

These two examples would be strong arguments against supporting this IMO. I would rather Angular fail silently in those two cases.

For your case, you could always create a custom filter to format it as desired.

[ewinslow]

Right now angular shows "{}" for the above example. That's not even weirder than calling toString()?

Current behavior is silly. Let's improve it. Throw a useful error, or call "toString", or concat with a string, but don't just show curlies or enter into an infinite loop...

[ewinslow]

Also: '' + x gives a consistent result regardless of the type of x, so far as I can tell (i.e. calls toString()). The one rub is that for null, false, and undefined it gives "null", "false", and "undefined" respectively, when you might want that to be empty string instead. Those can be trivially special-cased if need be.

[lgalfaso]

Hi, there is always a constant struggle between

• Failing silently, and developers spending hours trying to figure out why something is not working
• Failing every single time something is out of order, and end up very inflexible
• Being too flexible by picking a behavior, and not making everybody happy as this will not be the behavior some are expecting

In most cases, the answer is a balance. We needs to be flexible and at the same time let developers know when there is something that is not supported/will not work. On top, semver rules should be followed for breaking changes.

With this in mind, I find the behavior to be acceptable. Now if the consensus is that calling toString, then this cannot happen in a minor release, and 1.5 would be the first opportunity.

[ewinslow]

If this is a breaking change then semver means it has to wait until 2.0. :(

[ewinslow]

But thanks for getting back. I can definitely appreciate the bind you guys are in and it's easy to think that something is the right way just because it makes sense to me, but that is obviously not always the case.

[yordis]

👍 This should be the expected behavior. @wesleycho if you dont want to see '[object Object]' I prefer customize the toString function rather than create a filter. Your suggestion is create a filter per every single different output, that's more work and more code so more bugs 😄

[wesleycho]

@yordis a developer should not have to monkeypatch toString - that is a bad workaround. In this case, I absolutely prefer an api where the developer makes explicit how he/she wants it to be displayed.

[yordis]

@wesleycho Is that monkeypath? Why? For me it's prototype inheritance.

If you know the object have to output something different than the normal output, you just override the function. _Why don't use the flexibility of the language_, developers need to know what they are doing. If you are a javascript developer and you know how the toString is used it in Javascript there is not problem.

Every object has a toString() method that is automatically called when the object is to be represented as a text value or when an object is referred to in a manner in which a string is expected. By default, the toString() method is inherited by every object descended from Object. If this method is not overridden in a custom object, toString() returns "[object type]", where type is the object type." MDN

What's wrong with this.

function Person (firstname, lastname) {
  this.firstname = firstname;
  this.lastname = lastname;
}
Person.prototype.toString = function() {
  return this.firstname + ' ' + this.lastname;
}

var me = new Person('Yordis', 'Prieto');

Person.toString() //function Person (firstname, lastname) { this.firstname = firstname; this.lastname = lastname; }
me.toString() // "Yordis Prieto"

function you() {}
var fo = new you()

you.toString() // "function you() {}"
fo.toString() // "[object Object]"

I am programming in Ruby using RoR and you see a lot of Ruby extension from RoR making the language even better. I said this because we put too many limitations to Javascript making us full depended of browser providers. I am telling you that because the monkeypatch thing call my attention. The prototype inheritance is there, use it!

[tonte-pouncil]

I think it should call the toString() method. If the $parse service doesn't call toString() method, what does it call?