12/15/2005

 

Duck Typing

Yesterday, I talked about the Dynamic Overloading. Today, let's focus on the duck typing with by the way is what OO should be in classical way. First of all, the philosophy again: If it walks like a duck and quacks like a duck, it must be a duck. Actually, the real philosophy behind, I have to say is Ontology. That is what a object really is, is depending on what kind of operations it supports. Here the kind I mean the semantic of the operation. Let's compare the static strong typing against duck typing: public void func(someType a) { a.someField... } def func(a) a.someField The two are pretty the same, except in static case, when you call func with a, the compiler will check the type of a to see if it is of type someType, and to check if the type someType has a field someField. But in static case, only the type if has the field someField is checked, and it is been checked in runtime by the runtime envrionment rather than the compiler. The tiny difference between the two, to check or not to check the type, makes the duck typing not only more handy but more realistic. Why I am saying this? The biggest reason is the duck typing more focused on the semantic rather than the stupid static typing which assumes everyone can be the god to judge everything's type. When you call a method named "transfer" against a object, you knows what the transfer should be. There is no static type to gurantee what function you are actually calling. You think about the semantic here, rather than guessing the behavior of the codes already exists. So the name of the field and method in the duck typing is very very important. Because it is not only a name but also says something about what it about. It replaces the position of "class" or "type" in static typing language. The name itself reprents all your intention instead of both type and name in static typing case(i.e. you have to use the right type with the right name, you can get right you want). So, the burden of the "name" becomes heavier than the "name" used to be. In the past, the "name" is rather trivial, you have to give the type first, but as the type given, you can not mess the name up. But the sad thing is, the "name" in duck typing is too important to carry the burden. The problem we are struggling with like Refactoring especially "rename" is one of them. It all comes from the possiblity when we say I need a field named "xxx" that we are actually not pointing to the same thing. It can be a big problem, I don't Unit Test can hide cover all the defects, although I do believe Unit Test is much more important than static typing. This is only a begining, I will go further tomorrow. see you

This page is powered by Blogger. Isn't yours?

Subscribe to Posts [Atom]