>>Another example is that Python supports "Duck Typing", that is >>its type checking is protocol based. > > I see your point, but duck typing seems awfully implicit and > behind-the-scenes.
When you first encounter it it is. I came from a C++ and Pascal background where strict typing was the rule, Python seemed very lax. But I had the advantage of having worked in Lisp and Smalltalk too so I kind of relaxed fairly quickly. > Seems like if I expect a protocol, and you provide something that claims > to > implement said protocol, there ought to be some contract that ensures > we're > dealing with the same protocol. I ought not to be able to pass my car and > my nose to the same function, just because the both run(). It depends. Obviously in this example its likely that the behaviour would result in boizarre results but on the other hand if the function was race(obj1, obj2) then both car and nose could be appropriate, but in the latter case with rather horrible connotations... But seriously, Duck Typing allows for a far more expreessive and powerful use of objects. When you are no longer bound by the limitations of inheritance heirarchies you can start to build much more powerful funcions. The downside is that there is an onus on the client to sanity check the usage of the function - will it really do what I expect? Alan G Author of the learn to program web tutor http://www.freenetpages.co.uk/hp/alan.gauld _______________________________________________ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
