You can do this same thing in C to get Objects.
Also I believe there may be a typo in your last paragraph
>while staying clear of the brittle mess than is inheritance
It should be "that" instead of "than", I think.
Also I believe there may be a typo in your last paragraph
>while staying clear of the brittle mess than is inheritance
It should be "that" instead of "than", I think.
You can use objects in C, and there's numerous in-the-wild big examples. But you have to implement it yourself or use some library, and there isn't one "standard" for the language.
Go clearly does have some features designed to make objects a first-class element. Equally clearly there are some other languages that have "more" such features.
This post I'm making is merely descriptive; there's no positive or negative attached to these statements.
You can have structure members that are function pointers which is basically attaching a "method".
import itertools
class Test():
def __init__( self, number ):
self._number = number
return
def aaa( self ):
print 'AAA<%s>' % str( self._number )
return
def bbb( self ):
print 'BBB<%s>' % str( self._number )
def main():
instances = [ Test( n ) for n in range( 100 ) ]
functions = [ Test.aaa, Test.bbb ]
for instance, function in zip( instances, itertools.cycle( functions ) ):
function( instance )
if __name__ == '__main__':
main()I say "not typically" because there are still languages conventionally called OO that can do that, like Python and Javascript.
I take a pretty expansive definition of OO, pretty much the same one the author of the post takes, on the grounds that it isn't that helpful to insist that Javascript or Go isn't an "object oriented" language, because then one must sit there and explain what they are. They clearly aren't "procedural", excepting to the extent that Java is "procedural" (i.e., used as opposed to functional or declarative). And in the end, while there are significant dialect differences within the family of OO languages, when you start your language with a binding between methods and structures (be it a class or a prototype or a whatever), you end up with the same sort of end language. When viewed from the perspective of Haskell or SQL, Go and Java are next-door neighbors, even if within the mighty city of Object Orientation they consider themselves distant. Really persnickety definitions of "OO" just don't match to the programming reality very well. Argue as much as you like about whether one must "really" have a particularly persnickety definition of Polymorphism or whether you "must" have a concept of "private", but in the end, a project optimally done in Java, Python, Go, and $OTHER_OO_LANGUAGE will often end up pretty similarly structured. (And I'd observe to the extent that is not true, the spoilers will be something unrelated to OO like concurrency support or runtime characteristics, not details of the OO.)
Go is definitely an object-oriented language. It lacks classes, but those aren't required. We might argue that structural subtyping isn't really very OO. But given Go's lack of generics, this is a moot point.