Well said, Daniel.
On Sat, Dec 28, 2013 at 5:01 PM, Daniel Tabuenca <dtabu...@gmail.com> wrote:
> 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.
>
--
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.
