On Sun, Mar 9, 2014 at 10:49 PM, flebber <flebber.c...@gmail.com> wrote: > I was wondering if a better programmer than I could explain if the removal of > OO features in golang really does offer an great benefit over python. > > An article I was reading ran through a brief overview of golang in respect of > OO features > http://areyoufuckingcoding.me/2012/07/25/object-desoriented-language/
The description of how Go structs work is accurate from what I know of it, but I think the author goes astray in claiming that this is not OOP. If you look at how C++ compiles inherited classes, it works in basically the same way. The SmallBox class in C++ is essentially a struct with its fields laid out in a specific order and some methods that operate on it. A BigBox class that inherits from SmallBox will first lay out the SmallBox fields in the same way that SmallBox does, and then add the fields specific to BigBox after. Draw an imaginary line around the SmallBox fields, and you have the same setup as the Go example: a SmallBox nested within a BigBox. SmallBox methods will only operate on the portion of BigBox that is within the imaginary line (i.e. the SmallBox) and don't need to have any knowledge that the SmallBox is part of a larger data structure. BigBox methods can operate on the entire BigBox and can call SmallBox methods when desired. The author points out that nested structures can be made optional by including a pointer to the structure instead of the structure itself. Again you can do the exact same thing in C++; in OOP this is usually described as a "has-a" relationship. Most languages don't support the syntactic sugar that makes this look almost identical to inheritance in Go, but that's all it is. The biggest difference between the two is that Go doesn't have any concept of virtual methods. A call of a SmallBox method on a SmallBox object, whether part of a larger object or not, will always call that SmallBox method. Whereas a call to a C++ method that is compiled as a virtual method will actually call the method associated with the superstructure, regardless of the static type the method was called on. Go gets around this by using interfaces. An interface that is satisfied by SmallBox will usually automatically be satisfied by BigBox also, and calls to interface methods are dispatched dynamically. As a result, object-oriented Go code will typically work with interfaces rather than specifying actual classes, which is not too different from how Java code is typically written. Incidentally, I rather like the design of Go interfaces. They are essentially Python's duck typing made explicit, divorcing interface implementation from formal inheritance. On the whole though I think that the language is not yet mature enough to be able to seriously compete with more established languages like Python or Java. -- https://mail.python.org/mailman/listinfo/python-list
