> <i>So, the next time you’re about to make a subclass. Think hard and ask yourself — what would Go do.</i><p>I enjoy using both languages (Objective-C by day, Go by night), but I'm not sure this advice is necessarily something I would follow.<p>Because at the root of it all, Go is procedural and Objective-C is object-oriented. But the word "procedural" (or "imperative") isn't mentioned <i>once</i> in this blog post...it seems as if maybe the author missed something here? For example:<p>><i>In Go, composition of existing classes is trivial</i><p>...classes simply don't exist in Go. Composition of <i>interfaces</i>, yes, not classes. And maybe that's me being picky, but I think it's a really important distinction. One of the reasons I think the author found taking this further "incredibly difficult" is that the two methodologies <i>are</i> very different and perhaps shouldn't mix.<p>Maybe other people will have differing views, but I honestly don't know whether it is <i>worth</i> trying to impose a procedural viewpoint onto a overtly object orientated language (or vice versa). So to throw this open: am I missing something here?
All well and good, but keep in mind there's a fair bit of boilerplate to this way of composing classes and you don't get any type checking when you use dynamic forwarding.