4 ms·

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 inh

by AUmrysh 12y ago

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.

jerf 12y ago
C is not an object-oriented language because it has no language features intended to make objects easier to use or work with. You can't actually attach "methods" to structs in C. 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.
- slm_HN 12y ago
  "You can't actually attach "methods" to structs in C." You can have structure members that are function pointers which is basically attaching a "method".
  - pdpi 12y ago
    You still have to explicitly pass a `this` to that function, which is kind of my earmark for telling methods and functions apart. (In this regard, Python treads a fine line where it has an explicit `self` parameter that is passed in automatically).
    - knome 12y ago
      You can manually pass in the `self` parameter to unbound methods if you like. 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()
  - jerf 12y ago
    In that case you get something not typically associated with "OO", which is the ability to override a method on a per-object basis. 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.)
- seanmcdirmid 12y ago
  C has nice infrastructure for building v-tables that I found very useful back when I was writing in C. Heck, I wasn't even aware that I was merely reinventing objects at the time. 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.
- AUmrysh 12y ago
  Thank you for clarification. I've not really used Go, so I don't know how it differs from C for objects. I'm a little familiar with using structs in C for OOP, I apologize if my comment came across as to lessen the article, because I found it pretty interesting, and I love to see things like this where a new programmer might have their eyes opened to something those of us who've been around a while might already know from somewhere else.

by AUmrysh 12y ago

jerf 12y ago

C is not an object-oriented language because it has no language features intended to make objects easier to use or work with. You can't actually attach "methods" to structs in C. 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.

slm_HN 12y ago
"You can't actually attach "methods" to structs in C." You can have structure members that are function pointers which is basically attaching a "method".
- pdpi 12y ago
  You still have to explicitly pass a `this` to that function, which is kind of my earmark for telling methods and functions apart. (In this regard, Python treads a fine line where it has an explicit `self` parameter that is passed in automatically).
  - knome 12y ago
    You can manually pass in the `self` parameter to unbound methods if you like. 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()
- jerf 12y ago
  In that case you get something not typically associated with "OO", which is the ability to override a method on a per-object basis. 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.)
seanmcdirmid 12y ago
C has nice infrastructure for building v-tables that I found very useful back when I was writing in C. Heck, I wasn't even aware that I was merely reinventing objects at the time. 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.
AUmrysh 12y ago
Thank you for clarification. I've not really used Go, so I don't know how it differs from C for objects. I'm a little familiar with using structs in C for OOP, I apologize if my comment came across as to lessen the article, because I found it pretty interesting, and I love to see things like this where a new programmer might have their eyes opened to something those of us who've been around a while might already know from somewhere else.