12 ms·

I don't know if it's best, but I took on OOP in little bites: - ECMAScript 5 Mixins, scopes, instance variables, and instantiation. As a bonus, but not OOP,

I don't know if it's best, but I took on OOP in little bites: - ECMAScript 5 Mixins, scopes, instance variables, and instantiation. As a bonus, but not OOP, callbacks. It's a straight-forward language that's available abundance. - Python For it's class inheritance being easy to navigate. Instance variables, instantiation, method resolution order (MRO), mixins. - C++ This is the hardest language I can think of. It does everything OOP, and more, including allowing for a lot of stuff that's not legible. Despite that, it's a solid language. Something that goes great with constraining the many features of C++ are https://google.github.io/styleguide/cppguide.html https://google.github.io/styleguide/cppguide.html or https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines. I think ES5 and Python are used very often and in terms of bang for the buck, give they cover a lot of the bread and butter OOP concepts.

panic 9y ago
C++ doesn't do everything OOP: it doesn't support the late bound message-send style OOP of Smalltalk at all. In particular, you can't implement #doesNotUnderstand: (http://wiki.c2.com/?DoesNotUnderstand http://wiki.c2.com/?DoesNotUnderstand) or replace one object with another unless they have a superclass-subclass relationship.
- git-pull 9y ago
  It's the first time I heard of #doesNotUnderstand Despite it looking cool and useful, IMO it's more of a (quite pleasant) sugar than an OOP concept. There's also a try/catch example where you'd get similar behavior. I feel this is a bit opinionated: > "but this is clearly rather verbose and it has to be repeated for every call." I think the example in the link is what try/catch is meant for. Message passing systems in C/C++ handle situations where a disabled/unavailable service receives communication and recovers. As for C++ and replacing objects: I feel this is also a language-specific gotcha that doesn't hinder a learner understanding OOP. But C++ has many more gotchas than that. For instance, there's no pure "interface" keyword. It can still be done (and is), code example: https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Ri-abstract https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines..., how Google Style guide defines it: https://google.github.io/styleguide/cppguide.html#Interfaces https://google.github.io/styleguide/cppguide.html#Interfaces
  - panic 9y ago
    In C++, if you try to call obj->method() where `method` is not defined on the object, it won't throw an exception: it simply won't compile. In Java, the "class cast exception" is a somewhat different concept. Even if both classes support the same method, you can't cast between them if they don't have a superclass-subclass relationship. The core difference is "late binding" -- in languages like Smalltalk, the mapping from names to methods is evaluated at runtime, not at compile time like Java or C++. Looking things up at runtime makes the system less efficient, but makes it easier to change pieces of the system independently.
    - git-pull 9y ago
      > In C++, if you try to call obj->method() where `method` is not defined on the object, it won't throw an exception: it simply won't compile. I read the page, I liked it. It shows a try/catch is how it'd be done. > In Java, the "class cast exception" is a somewhat different concept. Even if both classes support the same method, you can't cast between them if they don't have a superclass-subclass relationship. I find that fascinating. But still, another case where it's more a rule and intricacy of the language. This is the latest C++17 draft (2017-03-21) http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4659.pdf http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n465.... So here's why I go on about it being an intricacy of the language: The amount of casting / type rules and so on in C++, for instance, is mind-boggling. > The core difference is "late binding" -- in languages like Smalltalk, the mapping from names to methods is evaluated at runtime Which is interesting. And cool. Isn't that similar to, an extent, virtual functions / vtable'd methods in C++? But how does this wrap into C++ not handling an aspect of OOP? In your words. Even though I feel #doesNotUnderstand is a sugar and not necessarily a whole OOP concept, I think it can handled via an event system and try/catches.
      - panic 9y ago
        Here's a concrete example: say I want to write a class which wraps an object, logging all the methods called on it. So if I say (in C++-ish syntax): Dog *dog = new Dog() LoggingWrapper *wrapper = new LoggingWrapper(dog) wrapper->runAround() The program should output a log entry like "Dog->runAround() called", then the dog should run around. In Smalltalk, you can implement `LoggingWrapper doesNotUnderstand:` to output the log entry; something like: doesNotUnderstand: aMessage Logger log: target class, ' ', aMessage selector, ' called'. ^ aMessage sentTo: target. It's not impossible to implement a class like LoggingWrapper using vtables -- in order to make a vtable, you have to know all a class's methods at compile time, but LoggingWrapper can respond to any method its target responds to.

panic 9y ago

C++ doesn't do everything OOP: it doesn't support the late bound message-send style OOP of Smalltalk at all. In particular, you can't implement #doesNotUnderstand: (http://wiki.c2.com/?DoesNotUnderstand http://wiki.c2.com/?DoesNotUnderstand) or replace one object with another unless they have a superclass-subclass relationship.

git-pull 9y ago
It's the first time I heard of #doesNotUnderstand Despite it looking cool and useful, IMO it's more of a (quite pleasant) sugar than an OOP concept. There's also a try/catch example where you'd get similar behavior. I feel this is a bit opinionated: > "but this is clearly rather verbose and it has to be repeated for every call." I think the example in the link is what try/catch is meant for. Message passing systems in C/C++ handle situations where a disabled/unavailable service receives communication and recovers. As for C++ and replacing objects: I feel this is also a language-specific gotcha that doesn't hinder a learner understanding OOP. But C++ has many more gotchas than that. For instance, there's no pure "interface" keyword. It can still be done (and is), code example: https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Ri-abstract https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines..., how Google Style guide defines it: https://google.github.io/styleguide/cppguide.html#Interfaces https://google.github.io/styleguide/cppguide.html#Interfaces
- panic 9y ago
  In C++, if you try to call obj->method() where `method` is not defined on the object, it won't throw an exception: it simply won't compile. In Java, the "class cast exception" is a somewhat different concept. Even if both classes support the same method, you can't cast between them if they don't have a superclass-subclass relationship. The core difference is "late binding" -- in languages like Smalltalk, the mapping from names to methods is evaluated at runtime, not at compile time like Java or C++. Looking things up at runtime makes the system less efficient, but makes it easier to change pieces of the system independently.
  - git-pull 9y ago
    > In C++, if you try to call obj->method() where `method` is not defined on the object, it won't throw an exception: it simply won't compile. I read the page, I liked it. It shows a try/catch is how it'd be done. > In Java, the "class cast exception" is a somewhat different concept. Even if both classes support the same method, you can't cast between them if they don't have a superclass-subclass relationship. I find that fascinating. But still, another case where it's more a rule and intricacy of the language. This is the latest C++17 draft (2017-03-21) http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4659.pdf http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n465.... So here's why I go on about it being an intricacy of the language: The amount of casting / type rules and so on in C++, for instance, is mind-boggling. > The core difference is "late binding" -- in languages like Smalltalk, the mapping from names to methods is evaluated at runtime Which is interesting. And cool. Isn't that similar to, an extent, virtual functions / vtable'd methods in C++? But how does this wrap into C++ not handling an aspect of OOP? In your words. Even though I feel #doesNotUnderstand is a sugar and not necessarily a whole OOP concept, I think it can handled via an event system and try/catches.
    - panic 9y ago
      Here's a concrete example: say I want to write a class which wraps an object, logging all the methods called on it. So if I say (in C++-ish syntax): Dog *dog = new Dog() LoggingWrapper *wrapper = new LoggingWrapper(dog) wrapper->runAround() The program should output a log entry like "Dog->runAround() called", then the dog should run around. In Smalltalk, you can implement `LoggingWrapper doesNotUnderstand:` to output the log entry; something like: doesNotUnderstand: aMessage Logger log: target class, ' ', aMessage selector, ' called'. ^ aMessage sentTo: target. It's not impossible to implement a class like LoggingWrapper using vtables -- in order to make a vtable, you have to know all a class's methods at compile time, but LoggingWrapper can respond to any method its target responds to.