Best possible marriage of static and dynamic typing?
http://lists.motion-twin.com/pipermail/neko/2010-January/002717.html > The problem can be more generally classified as one of conflation of the > granularity of inheritance... [snip] > I explained in a prior post that type safety is important when reasoning > about public interfaces that can be used for infinite combinations by > external users... [snip] > ...Thus, I have made the point that for HLLs public > interfaces interoperability we need simple type safe composeable public > interfaces... [snip] > Note that I have not claimed that strict typing solves LSP (granularity > does only to the point more granularity is needed to avoid a > composeability deadlock/conflict)... [snip] > I am claiming that at the layer for > (potentially infinite variations of use of) public interoperability of > interfaces, then strict typing is superior to proliferation of runtime > checks and exceptions... [snip] The following page shows that speak() is the interface used in command(): http://mindview.net/WebLog/log-0025 I would have preferred the static type example used ISpeak interface (requiring a speak() method) instead of virtual method for speak(). In any case, Python does not check for the existance of speak() method until runtime. Thus dynamic (runtime) typing gives infinite granularity of interface composition. I am advocating that if command() is to be a public interface consumed in the unknown wild, then it should specify that it expects an ISpeak argument, so that statically typed HLLs can enforce this. Perhaps the best marriage between static and dynamic type to give us the greatest granularity combined with the advantages of static checking, would be to consider two interfaces equivalent if they have the same members (including argument list and return type for method members)? Thus, assigning a ITalkAndSpeak (contains talk() and speak()) to an ISpeak would be allowed. The disadvantage is that the interfaces members may not be designed to be useful orthogonally, i.e. we break a contract, and members have the same name and type may not have the same semantics. But those problems apply to dynamic typing always, thus we do no worse than dynamic typing. The alternative is to build the most granular and orthogonal interfaces, i.e. if ITalkAndSpeak inherits (composition of) ITalk and ISpeak, then ITalkAndSpeak can be assigned to ISpeak (and ITalk). In any case, then when calling from a dynamic to static typed language, the dynamic language (or the VM layer?) would be responsible at runtime for testing the objects it passes as arguments. And when calling from static to dynamic, the static language would be responsible for not enforcing any type on the arguments. I hope this has really made it clear that Linkov Substitution Principle (LSP) is really all about granularity of semantics of interfaces. I suppose everyone knew this already, but hopefully these posts helped clarify it in some ways. -- Neko : One VM to run them all (http://nekovm.org)
