On Apr 24, 8:37 am, egervari <ken.egerv...@gmail.com> wrote: > Still, I think people like the fact that they can do duck typing and > not have to get into hairy inheritance models that don't make sense. > That stuff can and does get complicated, and the duck typing solution > is actually pretty simple. Having said that, there are ways to get > duck typing semantics in a static typing language like scala ;)
Not efficiently. Scala supports something called "structural typing", which Scala users will claim is "as good as duck typing". In a way it is; you can specify statically that you want all objects passed to you support a particular set of methods. That's almost duck typing, where you just call the methods and damn the torpedos. But there's a catch... Scala's structural types can't be implemented with normal Java types, and so Scala uses reflection to implement them. This is a common theme among statically-typed languages. They work great as long as all types, method calls, parameters, variables, and so on can be specified up-front for a compile phase to bind it all together. But the real world isn't quite as perfect; you eventually want to be able to reflectively load a class or call a method. If you've ever done that, you're no longer obeying the rigor of your statically-typed language of choice, and you've started to take advantage of dynamic-language features (albeit in a very roundabout way). At its simplest, dynamic typing could be thought of as always- reflective programming. And of course most dynamic languages do a lot more than that, like allowing you to add and remove methods to classes at runtime, something that's literally impossible to do in a statically typed language. And let's not pat ourselves on the back too much about how static our languages are; I can defeat the static typechecking of any JVM language by loading different versions of classes underneath you. If you've ever gotten IncompatibleClassChangeError, you're seeing the true nature of the JVM: it's dynamically binding almost all calls anyway. You just don't see that fact as often as for a formally "dynamic" language since static-typed languages wrap a nice warm compiler blanket around you and say "everything will be all right". All these languages exist on a continuum; none are entirely static or entirely dynamic. What varies is how much up-front specification you have to put in your code in order to start the program running, and what set of guarantees that specification affords your program at runtime. Sometimes it's fine to specify everything to the letter, and sometimes you'd like to just be able to call "foo" on some object "bar" without knowing the exact type. These are different tools for different problems; none of them are the one true tool, and none of them are "you know what". - Charlie -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to javapo...@googlegroups.com. To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
