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

51–60 of 89 posts

Re: Is Go Duck-Typed?

#51

Post by gowld »

derefr wrote: post #43
Footkerchief wrote: post #38

Earlier quoted context omitted.

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.

When you're talking about type systems, "dynamic" really doesn't make much sense to talk about. It's not like the runtime constructs a typing model out of its observations of the properties of objects' runtime interactions. The notion of there being a "type" to a duck-typed object is purely a theoretical one; in practice, the object just does whatever it wants moment-to-moment, and the runtime has no idea. Consider a…

Arguing about definitions is old and boring. https://en.m.wikipedia.org/wiki/Type_system

Re: Is Go Duck-Typed?

#52

Post by jolux »

bjz_ wrote: post #29
masklinn wrote: post #24

Earlier quoted context omitted.

> languages like Standard ML and Typescript that tend to be more structural. AFAIK SML is nominal. OCaml has a structural subsystem in that its object system is structural. The vast majority of the language is nominally typed. > It's probably more that most mainstream typed languages, like C, C++, Java, C#, etc. have mainly gone down the nominal route It's not just mainstream typed languages. Almost all statically ty…

> AFAIK SML is nominal I guess I was referring to how records are structural. Although granted tagged unions are nominal, and you can get nominal typing through modules. I was probably wrong in posing it as 'one or the other' - seeing as many languages have a mix of both. I'm definitely not saying that nominal typing is bad, it's just that it's nice to have the option to go structural if you want, and many have not k…

Are records structural in Standard ML? What happens if you have multiple records with the same structure but different names? I thought structural typing of records was not very useful without row polymorphism.

Re: Is Go Duck-Typed?

#53

Post by jolux »

_old_dude_ wrote: post #37
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;

Isn't this just the stuff making all lambdas implicitly implement a single-method interface and such?

Re: Is Go Duck-Typed?

#54

Post by bjz_ »

jolux wrote: post #52
bjz_ wrote: post #29

Earlier quoted context omitted.

> AFAIK SML is nominal I guess I was referring to how records are structural. Although granted tagged unions are nominal, and you can get nominal typing through modules. I was probably wrong in posing it as 'one or the other' - seeing as many languages have a mix of both. I'm definitely not saying that nominal typing is bad, it's just that it's nice to have the option to go structural if you want, and many have not k…

Are records structural in Standard ML? What happens if you have multiple records with the same structure but different names? I thought structural typing of records was not very useful without row polymorphism.

Records of the same structure but different names are equivalent. In fact tuples are just sugar over records with numeric fields starting from 1. Note that this is not the same as in OCaml, afaik.

Re: Is Go Duck-Typed?

#55

Post by superlopuh »

zwieback wrote: post #7

I like the histogram showing how much more frequent interfaces with just one or two methods are. How frequent are problems where classes unintentionally use an interface due to identical signatures? Seems likely to happen in theory if so many interfaces have few functions.

Anecdotally, this happened to me today

Re: Is Go Duck-Typed?

#56

Post by flippinburgers »

Structural Typing is being used, but unlike the wikipedia article being linked to by mbell, I don't think the distinction between duck typing and structural typing is that significant. It boils down to does the method parameter, which is an interface, describe the subset of the struct that you require or not? That is it. It is duck typing, but it simply requires explicit definitions (interfaces).

To use a popular quote "if it acts like a duck-type it is a duck-type".

Re: Is Go Duck-Typed?

#57

Post by seertaak »

steveklabnik wrote: post #47
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,…

Neg is used to implement operator overloading for unary minus; it's unclear how you would implement this functionality without only doing one thing.

Thanks for clarifying that; I was actually aware of the link to syntactic sugar and it's probably true that you want to control that independently. After all, who doesn't want to hijack unary minus for the purpose of as hackneyed rendering of EBNF? C++ certainly does it :)

Anyway a serious answer to your comment would be to create a field or ring concept. This would unify some or all of the arithmetic operations.

A neat bonus would be the ability to overload the one and zero literals for the set. So in field of nxn matrices on real numbers 0 is the zero matrix and 1 is the identity.

Re: Is Go Duck-Typed?

#58

Post by LessDmesg »

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

The difference is small, and the fact remains: structural typing is utter crap, and so is Go.

Re: Is Go Duck-Typed?

#59

Post by _old_dude_ »

jolux wrote: post #53
_old_dude_ wrote: post #37

Earlier quoted context omitted.

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;

Isn't this just the stuff making all lambdas implicitly implement a single-method interface and such?

yes, a lambda is (mostly) desugared as a static method and then the operator :: is applied.

Re: Is Go Duck-Typed?

#60

Post by GlitchMr »

taklon wrote: post #39
_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…

> 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 typ…

While Go interfaces are usually checked at compile time, this doesn't have to be the case - you don't even have to use reflection. Consider the following program.

    package main

    import "fmt"

    type Dog struct{}

    func (d Dog) NumberOfLegs() int {
        return 4
    }
    func (d Dog) Genus() string {
        return "Canin"
    }

    func main() {
        var dog interface{} = Dog{}
        fmt.Println(dog.(interface{ NumberOfLegs() int }).NumberOfLegs())
        fmt.Println(dog.(interface{ Genus() string }).Genus())
        fmt.Println(dog.(interface{ Happy() bool }).Happy())
    }
This fails at runtime, as `Dog` doesn't have `Happy` method.
Post reply on HN