There’s two notions at play here, one is object-oriented programming (which javascript handles quite well), the other is a static typing system (which javascript being a dynamic language doesn’t natively support).
It’s important to understand that you can do object-oriented programming without static typing, classes, explicit interfaces, or inheritance. Similarly, just because you are using classes, interfaces, or inheritance doesn’t mean your code is object-oriented. I understand why you are troubled by the notion that you shouldn’t just be able to trust an object implements the correct interface simply because it has methods with the right names. Technically speaking, you are absolutely correct. The push method of an object I pass in might very well just do a window.alert('I'm not pushing'). However, what you have to realize is that there is always an implicit contract between methods and API’s you write, and the people who use those API’s. When you write a function, you have to document or show examples of what it does, what parameters it expects and what it will return. A statically typed language provides some tools to help document and enforce *some* of that contract at compile time. However, static typing can only go so far to enforce a contract, so you still have to trust the caller. For example, even with static typing I can create a group and have it implement a “List” interface but there is nothing preventing me from implementing the list interface incorrectly, or even purposefully not behaving as a faithful implementation of a list contract (i.e. I can still “push” persons off a cliff rather than add them to my group). Duck-typing can be a useful tool in dynamically typed languages, as long as your contracts is documented. For example, in your method you would say: “if the first parameter proviides a push method it will be interpreted as an array-like object and the method used to add items to it”. While this contract is not enforced by the language itself or the compiler, it is still a contract nonetheless. If the user of your method chooses to pass in an object with a push that does something other than what the contract requires, they should not expect it to work correctly. We use these kind of contracts all the time in angular and don’t think much of them. Take for example controller definitions, they take a string and a constructor, but the constructor could be a function, or it could be an array where where each element is a string and the last element is a function (for dependency injection). So the following two are valid ways of defining a controller: app.controller('myController', function($scope){ }); app.controller('myController', ['$scope', function($scope){ }]); This is a contract we are all familiar with, but it’s not enforced by the language, I could pass an array of integers as the second parameters but it would not really work because I’m violating the contract in the documentation. I could pass a list of strings that don’t actually match any services in my module and angular would throw me an exception because the contract states that these strings should be the names of valid services. My point is that the contract is between a method and those who use the method. Static typing can only help partially document and enforce some aspects of the contract, but often not the entire contract, so there will always be a level of trust that the objects passed in to your function behave as specified in the contract (even when using static typing). -- You received this message because you are subscribed to the Google Groups "AngularJS" group. To unsubscribe from this group and stop receiving emails from it, send an email to angular+unsubscr...@googlegroups.com. To post to this group, send email to angular@googlegroups.com. Visit this group at http://groups.google.com/group/angular. For more options, visit https://groups.google.com/groups/opt_out.