type vs. interface: why typing then?
By broadening my horizons with javascript together with my python experience I put some thought.
What's the purpose of type if the vision of an entity to an external client is via its interface ?
In static typed languages, the type has a very strong, central importance. Type and interface are strictly associated. For example, in java when you declare an interface FooIface and an object implement that interface, you cannot use it in a context requiring BarIface, even if the two are exactly the same in terms of methods, signatures and exceptions.
Not so in python. Even if two objects have completely different and unrelated types, as long as their interface is the same, they are totally and transparently interchangeable. If it quacks and walks like a duck, it's a duck. I can completely change the nature of an object by completely altering its interface at runtime, but it will preserve the original type.
This point of view is put to the extreme in javascript, where every object in any prototype chain is just that, an object开发者_如何转开发. you ask the type of each object in javascript, and it will tell you just that, it's an object.
It appears to me that the concept of type for these languages is at the limit of futility. What is then really vital for ? Does type has a real meaning in dynamic typed languages?
I don't see futility. Consider:
1). When you construct an object
var myThing = new Thing( ... );
the Thing's type has significance.
2). A method of Thing can use
this.aProperty
according to its knowledge of type
3). You can use instanceof to determine a type
I tend to understand the word "type" as equivalent to the word "class" in Python. That's only 99% correct, but close enough.
>>> type(object)
<type 'type'>
>>> class X(object):
... pass
...
>>> type(X)
<type 'type'>
>>> type(_)
<type 'type'>
>>> type(X())
<class '__main__.X'>
>>> type(X) is type(type)
True
I do, however, usually avoid the word "type" in this case. In general, my way of seeing it is this: The word "type" implies that the thing in question is not a first-class object.
If a language only regards the implemented methods of a class to infer which interfaces it conforms to, you can implement an interface by accident. Lets say in Java you have the interfaces IA and IB which both define the method long getRemainingTime. In this case the contract of these interfaces would specify, what kind of format they would return (one could return the time in seconds, while the other returns the time in milliseconds). Also the context in which these interfaces are used can be very different. Lets say they are not called IA and IB but IProgress and IStopWatch. In such a case, the returned time would have very different meanings. If you were able to interchange these two interfaces as you liked, you might get really unexpected results.
In general the type can be seen as an aid to perform a rudimentary, static code analysis. If you implement a specific interface, the compiler can then tell you directly that you are probably making a mistake, if you try to pass an instance of your implementation to a method which expects a similar implementation but of a different type.
精彩评论