Go In Three Easy Pieces

Could you please link the slides and the video in golang.org once ready?

Thanks

Why did you decide to put types after variable names?

What is the motivation behind ad-hoc interfaces?

Instead of writing in comments about what interfaces we implement, wouldn't be better to a have more traditional inheritance, thus integrity checking?

I guess, go compiler produces warnings (or at least there is a switch) when you only partly implement some interface, doesn't it?

no video?

Sorry, I understood motivation behind ad-hoc interfaces, but question regarding integrity checking remains open.

@Zura: Go should definitely at least allow the conventional integrity checking. But except for that, the way interface are handled is quite nice. In C++ people already know that stuff, otherwise the STL would have been impossible. Ad-Hoc interfaces provide a great way of allowing sophisticated abstractions without endless headaches about type hierarchies. What happens if you don't do it the Go or C++ way is you end up with C# ^^. I really like C# too but that you can't have ad-hoc interfaces or at least runtime bound generics is a pain in the * for any generic facility.

Actually, I didn't mean runtime bound generics ^^. I meant the stuff that we have in C++. Something like threading any generic parameter as "dynamic" (the new C# keyword) and then at runtime, instead of doing a dynamic dispatch, which is slow, the CLR would see if it can statically compile the generic code with the specified arguments. If it doesn't work, it could throw a runtime exception for example... And of course the compiler can do that at compile time for statically typed code at least. (with no performance penalties) This is what is really missing in NET generics, I hope it gets implemented!

where's the video??

@Zura: There is a good article explaining Go's (type) declaration syntax on the official website here: http://golang.org/doc/articles/gos_declaration_syntax.html

@foo: The answer to all of your questions is here http://www.youtube.com/watch?v=Y1g2Cx03L2I

@Zura @Luna

You get integrity checking by assigning to a variable of interface type. If you don't need a variable, you can assign to '_' which acts as a sort of /dev/null. See http://golang.org/src/pkg/encoding/json/stream.go#L187 for an example, where lines 187 and 188 are verifying that *json.RawMessage conform to the json.Marshaler and json.Unmarshaler interfaces.

@agentS

Yes, but that is more like a trick/workaround. I think that implementing this as a compiler option - warning or error for partly implemented interfaces would be a better solution.

@Zura:

But, ad-hoc interfaces mean that any interface can implemented by any type, there's no implements keyword. How can the compiler know what types the programmer intended to implement a given interface. The example I gave is a way for the programmer to be explicit about his intent if he wants to be.

Assignments are checked statically. For example, if you pass something as the first argument to http://golang.org/pkg/fmt/#Fprintf, the compiler will ensure that it has an Write method with the appropriate signature (http://golang.org/pkg/io/#Writer).

In fact, even the trick I linked to isn't used very much in the standard library. The standard library is extensively tested, and just the fact that the tests compile often verify a lot of such cases.

I love ad-hoc\duck typing.  I think this is one of the best features in Go.  In C# it is very painful to get something close to duck typing\ad hoc interfaces without a lot of performance penalties..  I usually switch over to F# and static ^ types for my structural typing needs.  One of the biggest problems with any large code base in almost any language in my opinion are these weird object hierarchies that only the original designer can understand. (or maybe no one can understand)  The Managed Extensibility Framework (MEF) in an early preview version had great duck typing support but in the recent versions it has been removed.  I wish it was still there.