3 ms·
"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".
by 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 agoYou 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 agoYou 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 agoIn 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.)