Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Is Go Duck-Typed?

bionic.fullstory.com

Post reply on HN
Print view View original

31–40 of 89 posts

Re: Is Go Duck-Typed?

#31

Post by throwaway894345 »

_y5hn wrote: post #25
seertaak wrote: post #18

Earlier quoted context omitted.

I think it's really interesting to contrast this with Stroustroup's advice on concepts: "My rule of thumb is to avoid “single property concepts.”". He gives an excellent example leading to this dictum: single property interface "Drawable". Let Shape implement drawable with widely expected results. But: let Cowboy implement Drawable -- now with disastrous consequences. The solution to this dilemma is as stated above,…

For golang, single method interfaces are recommended as preferable. The problem with huge interfaces or classes is they can always become larger! While if you compartmentalize single responsibility into separate components (may be several methods if applicable to the domain and design), each reason to change may be restricted to that bounded context only. If not, it's a signal design might need revisit. The problem w…

Frequently in Go I find that single-method interfaces are easier to work with when made into a closure. Instead of `type Foo interface { Foo() }`, I often find `type Foo func()` easier to work with. There are probably exceptions to this; I'm mostly just voicing my own observation.

Re: Is Go Duck-Typed?

#32

Post by abhorrence »

_y5hn wrote: post #16
tgv wrote: post #15

Earlier quoted context omitted.

Wouldn't that make any language with reflection Duck-typed? That would suggest Wikipedia's definition is not very useful.

Fair question! "Duck typing" can be implicit, if you can call quack() on this() without error, you (the programmer) assume it's a Duck. The language may make it explicit (loosely structural typed like in golang, or other variations), or implicit (like in ruby). There are varying degrees, but you should be able to have a collection of the "Ducks" and be able to invoke quack() on them all. Can't really say I see the co…

Reflection isn’t required, but with sufficient reflection a language could essentially be extended to include duck typing.

Re: Is Go Duck-Typed?

#33

Post by _y5hn »

seertaak wrote: post #26
_y5hn wrote: post #25

Earlier quoted context omitted.

For golang, single method interfaces are recommended as preferable. The problem with huge interfaces or classes is they can always become larger! While if you compartmentalize single responsibility into separate components (may be several methods if applicable to the domain and design), each reason to change may be restricted to that bounded context only. If not, it's a signal design might need revisit. The problem w…

> The problem with huge interfaces or classes is they can always become larger! That's definitely a good reason to prefer small interfaces; I hadn't thought of that but it certainly makes sense. That said, I think we may be referring to different things when we use the word "property". Stroustroup is talking about properties in the mathematical sense, i.e. he's talking about the properties of the operation "draw()" i…

"Drawable" as a name is pretty bland, like patterns. Do we ever really say "drawable" out loud?

So I suspect if we seek more meaningful objects and models, they become more active, have better names, improved design, etc.

If you ask a janitor about Drawable, will he say it's all about draw()? So I think it's kind of a dreary default that we need to avoid and focus on who the actors are, what messages they will pass, and the hidden treasures they encapsulate (don't show, but tell!).

Re: Is Go Duck-Typed?

#34

Post by morelisp »

mrkeen wrote: post #11
mjr00 wrote: post #9

Earlier quoted context omitted.

In theory, yeah... in practice, as someone who uses Go and Python with mypy (which supports structural type-checking using the Protocol interface) professionally, I haven't seen it happen. It's easy to think of contrived examples like the one in the post, where Cat/Dog/Table all implement GetLegCount(), but in practice your interface methods usually aren't that simple, and interface signatures like func InsertFoo(*sq…

I tend to use nominal types a lot in other languages, so I have a lot of types with id() or value(). Would those be mixed up?

They would be, but it's also unlikely you would be able to write something useful using only the id and value such that you might confuse something.

There's some "self-limiting" - the smaller the interface, the more likely you get accidental implementation, but also the less likely you are to confuse them in a way that typechecks but actually does something unexpected.

A practical example might be io.Closer - I am certain I implemented this in a dozen types I never intend to pass to any io functions. But no io functions actually take just a Closer, and if I did write some generic cleanup routine that only requires a Closer, it's probably fine and maybe even good if it works on byte IO and gRPC connections and Kafka streams. (Especially without generics, it might be the best I can do.)

Re: Is Go Duck-Typed?

#35

Post by pansa2 »

mbell wrote: post #2

This is called Structural Typing[0] and is in contrast to Nominal Typing[1] (e.g. Java). 0: https://en.wikipedia.org/wiki/Structural_type_system 1: https://en.wikipedia.org/wiki/Nominal_type_system

I think the difference between structural typing and duck typing is one of explicitness. When passing an object `o` into a function `f`, structural typing enables `f` to explicitly say “`o` must support `a`, `b` and `c`”, even if `f` only ever calls `a` and `b`.

With duck typing, the interface is implicit - if `f` only calls `a` and `b`, then that’s exactly what `o` needs to support.

Duck typing also allows more dynamic interfaces, like “`o` must support `a`, and if calling `a` returns true, it must also support `b`”.

Re: Is Go Duck-Typed?

#37

Post by _old_dude_ »

mbell wrote: post #2

This is called Structural Typing[0] and is in contrast to Nominal Typing[1] (e.g. Java). 0: https://en.wikipedia.org/wiki/Structural_type_system 1: https://en.wikipedia.org/wiki/Nominal_type_system

Java type system is not fully nominal anymore, the operator :: does structural typing.

  interface I { void m(); }
  class A { void hello() { ... } }
  I i = new A()::hello;

Re: Is Go Duck-Typed?

#38

Post by Footkerchief »

lkitching wrote: post #20
_y5hn wrote: post #14

Earlier quoted context omitted.

Duck typing is according to Wikipedia: https://en.wikipedia.org/wiki/Duck_typing Duck typing as a concept was re(?)-popularized around the advent of ruby, so might make sense to talk from a ruby perspective: http://rubylearning.com/satishtalim/duck_typing.html With ruby, most everything you interact with is a true object, ie. you can modify behaviour of almost all classes/objects by adding/removing methods, mixin, et…

I'm not sure what you mean by 'not exact' since the article you posted explictly contrasts duck typing with structural type systems of which Go is given as an example.

The contrast in the Wikipedia article is:

> Structural typing is a static typing system that determines type compatibility and equivalence by a type's structure, whereas duck typing is dynamic and determines type compatibility by only that part of a type's structure that is accessed during run time.

That sounds like static vs. dynamic implementations of the same thing.

Re: Is Go Duck-Typed?

#39

Post by taklon »

_y5hn wrote: post #14
mbell wrote: post #2

This is called Structural Typing[0] and is in contrast to Nominal Typing[1] (e.g. Java). 0: https://en.wikipedia.org/wiki/Structural_type_system 1: https://en.wikipedia.org/wiki/Nominal_type_system

Duck typing is according to Wikipedia: https://en.wikipedia.org/wiki/Duck_typing Duck typing as a concept was re(?)-popularized around the advent of ruby, so might make sense to talk from a ruby perspective: http://rubylearning.com/satishtalim/duck_typing.html With ruby, most everything you interact with is a true object, ie. you can modify behaviour of almost all classes/objects by adding/removing methods, mixin, et…

> Golang furthers the notion of capabilities as shared method signatures, by loosely binding this into interfaces, and enforcing many errors by static type checks at compile time.

This, I think, is the main point of the parent comment.

I think the distinction (and overlap) come into focus when you think computationally: how is a type computed? Type semantics are determined by the type checker, and Go's interface types are checked at compile time. Duck type checking happens at runtime. There's no language support in Go for this, but the closest thing would be passing a bunch of empty interfaces around and using the stdlib's reflect package everywhere so that you never panic, but sometimes return a user-generated TypeError.

Sure, Go's interfaces allow clients to accept multiple concrete types, but that's checked at compile time, not runtime, and so it will never be duck typed.

Re: Is Go Duck-Typed?

#40

Post by samatman »

didibus wrote: post #23

I think duck typing is different from structural typing, and go is not duck typed, but structurally typed. I think the difference is that in duck typing, there is no real type. A thing is a duck if I can use it as one, and that same thing can be a chair if I can also use it as one. So on duck typing, we say, does it have the properties I need, if so I can happily use it, don't care what it is. And that can only be do…

I agree, and the difference is easy to illustrate.

quack() in duck typing, has to have no arguments and return a string (let's say). We can have a NotarizedDuck class where quack(true) instead returns the number of times the NotarizedDuck has quacked, so long as quack() itself returns a string, it will pass the unit test.

In structural typing, it's illegal to call that quack, because it's the wrong function signature.

Post reply on HN