5 ms·

Welcome to bounded polymorphism, circa 1989. A young Wadler would be pleased. An aside, it is not "duck typing" if it involves a static type system.

• voidlogic 14y ago
  Thanks right, technically Go supports a structural type system* which is a similar to, but different than duck typing. But the Go community often refers to Go as being duck-typed due as that term is more familiar to people coming from languages like Python. * http://en.wikipedia.org/wiki/Structural_type_system http://en.wikipedia.org/wiki/Structural_type_system
  • cgag 14y ago
    Isn't duck typing what would let it work without creating that new interface? Do you say it's like duck typing because you don't have to mention anywhere that your two previous interfaces satisfy your new interface?
    • mseepgood 14y ago
      Duck typing: "When I see a bird that walks like a duck and swims like a duck and quacks like a duck, I call that bird a duck." Translated to Go: "When I see a type with methods that satisfy this interface, then it implements this interface."
      • MatthewPhillips 14y ago
        But you still have an explicit interface.
        • _ak 14y ago
          But an implicit implementation of that interface.
        • NateDad 14y ago
          The interface just defines the methods an object must have to be passed into this function. No types have to "implement" the interface in the traditional sense. Anything that happens to have the same methods as are on the interface may be passed into the method that requires that interface. Basically, the interface just defines at compile time what Python defines at runtime... except it's a hell of a lot easier to see what methods are required for a Go interface, than it is to see what methods are required for a python function (you basically have to read the entire function and any function that function passes the argument to). Not that I don't like python, I do.
        • knome 14y ago
          The metaphor has an explicit duck.
    • voidlogic 14y ago
      My understanding: In duck typing only the part of the structure/method set accessed is checked at run-time for compatibility, in structural typing everything is checked at compile time (even if those checks follow loose duck-typing rules). To the programer they appear to be the same most of the time.
      • rquantz 14y ago
        I'm not the least bit a Go programmer, but it sounds pretty different from a programmer's perspective to me. With duck typing your methods end up with conditional logic based around respond_to calls. With Go it seems like it's declarative. Whether you like that or not, you have to admit it's pretty different for the developer.
        • deleted 14y ago
          [deleted]
        • voidlogic 14y ago
          "Whether you like that or not, you have to admit it's pretty different for the developer" I don't really think that is true in Go.
        • NateDad 14y ago
          You never have to declare what fulfills an interface in Go. The fulfillment is implicit. If you define an interface with the Quack() method, anything with a Quack() method on it can be passed into a function that takes that interface, even if that object has never heard of the interface or the function. You never declare that a type "implements" an interface in the way you do for languages like C++ or Java.
  • zemo 14y ago
    "often" is stretching things a bit. The reason this terminology popped up is that it was in the official documentation, but it was (or is scheduled to be) taken out. anyway, you're right, it's not duck typing. Duck typing happens at runtime. With Go, every variable has exactly one type at compile time. Sometimes that type is an interface type. With duck typing, the checking happens at runtime. There's no runtime type checking with Go's interface system.
    • unnali 14y ago
      > There's no runtime type checking with Go's interface system. Except when there is: http://golang.org/ref/spec#Type_assertions http://golang.org/ref/spec#Type_assertions
    • NateDad 14y ago
      Nothing says duck typing has to be at runtime. The only requirement to duck typing is "an object's methods and properties determine the valid semantics, rather than its inheritance from a particular class or implementation of a specific interface". This is exactly how Go's interfaces work. You define the methods you require an argument to have, and then anything that has those methods can be used as that argument, without the original type having any knowledge of the interface that was designed. The only difference between Go and Python in this regard is that Python doesn't actually define what a duck is for a specific method, it is implicitly defined by the methods that are called on it. Go explicitly defines what a duck is, which makes it a hell of a lot easier to know if the object you're passing in qualifies as a duck without reading every line in the damn function. Yes, go checks that an object is a duck at compile time, that doesn't have anything to do with duck typing.
      • Dn_Ab 14y ago
        It is true that duck and structural typing have only a subtle difference. But it is also true that duck typing has to be at run time essentially by definition. Structural typing looks for structural isomorphsims - it is total. Duck typing looks at run time compatibility, so long as the runtime accessed portion is the correct signature it passes. So structural typing is about isomorphisms and duck typing is about checking the correct boxes before entry. Both have the attribute of looking at structure but you cannot expect them to cluster types in the same manner. In ML* terms I like to think of structural typing making hard clusters and Duck typing allowing for soft clusters. * No, not that ML.
• cwzwarich 14y ago
  Bounded polymorphism was old news even by 1989. Boring imperative languages like CLU and Ada had it.
  • dons 14y ago
    True enough. Strachey '67 after all...
• MichaelGG 14y ago
  Can you clarify why it can't be duck typing if it's static? For instance, in F# you can declare a function that can take any type that provides a specific method name and signature. You can pass any object to such a function as long as it has that method - there's no other similarities required in the types you pass to it. How is that not "duck typing"?
  • edmccard 14y ago
    There is little difference between "structural typing" in go, where function signatures reference named and separately defined interfaces, and "static duck-typing" in F#, where function signatures using constraints effectively define an anonymous interface right there in the signature. In either case, type errors are detected at compile time. Some people prefer to use "structural typing" for both (maybe using "implicit structural typing" to describe what can be done in F#), and to use "duck typing" to describe languages without type-checking, where type errors only happen at run time. But it's all just terminology.