4 ms·

> many programmers now don't consider languages to be OOP unless they have the class keyword and inheritance. If a language doesn't support inheritance, in wha

> many programmers now don't consider languages to be OOP unless they have the class keyword and inheritance. If a language doesn't support inheritance, in what sense is it an object-oriented programming language? It's true that you can use OOP principles in languages that don't have language-level support for OOP. The canonical example of this is the GObject library for C. That doesn't tell us how we should use the term object-oriented programming language though. I don't see why we'd use a more expansive definition.

magicalhippo 7y ago
Thinking off the top of my head, how about a language that only had interfaces (ala COM)? Implemented by non-inheritable objects, using delegation instead of inheritance to share code. I imagine some syntax sugar to help with the delegation to make it less cumbersome.
hhas01 7y ago
Self doesn’t have classes or inheritance, and it’s as [single-dispatch] OO as they come. (Certainly moreso than something like C++, which wouldn’t look out of place on a Melanesian island. Never could figure why C++ and all its typed kin would choose to dispatch [dynamically] on only one argument instead of on all. Playing to their weaknesses, no?)
- MaxBarraclough 7y ago
  My guess is that by going with single dispatch, you get clear 'ownership' in terms of methods^H^H^H^H^H^H^H member-functions belonging to classes. Can't say I know a lot about multiple-dispatch though.
int_19h 7y ago
In every sense. Prototype-based OO has been a thing for a long time now. If you look at the entire breadth of OO languages and see what they have in common, there's really only two things that are truly common: object identity, and some form of dynamic dispatch based on that. Everything else - inheritance, encapsulation etc - is optional.
- MaxBarraclough 7y ago
  Prototype-based OO is a form of inheritance. > there's really only two things that are truly common: object identity, and some form of dynamic dispatch based on that. Everything else - inheritance, encapsulation etc - is optional. That's a broader definition than I had in mind, but I can see where you're coming from.
pmontra 7y ago
Sending a message to an Erlang / Elixir process to change its internal status (a GenServer) is not conceptually different than calling a method of an object. The big difference I see between Elixir and (example) Java or Ruby is that everything is an object in those languages but a big Elixir application has only a few GenServers, where keeping a state matters. Everything else is passed as argument, which by the way it's what a GenServer does internally with an endless tail recursion.

magicalhippo 7y ago

Thinking off the top of my head, how about a language that only had interfaces (ala COM)? Implemented by non-inheritable objects, using delegation instead of inheritance to share code. I imagine some syntax sugar to help with the delegation to make it less cumbersome.

hhas01 7y ago

Self doesn’t have classes or inheritance, and it’s as [single-dispatch] OO as they come. (Certainly moreso than something like C++, which wouldn’t look out of place on a Melanesian island. Never could figure why C++ and all its typed kin would choose to dispatch [dynamically] on only one argument instead of on all. Playing to their weaknesses, no?)

MaxBarraclough 7y ago
My guess is that by going with single dispatch, you get clear 'ownership' in terms of methods^H^H^H^H^H^H^H member-functions belonging to classes. Can't say I know a lot about multiple-dispatch though.

int_19h 7y ago

In every sense. Prototype-based OO has been a thing for a long time now. If you look at the entire breadth of OO languages and see what they have in common, there's really only two things that are truly common: object identity, and some form of dynamic dispatch based on that. Everything else - inheritance, encapsulation etc - is optional.

MaxBarraclough 7y ago
Prototype-based OO is a form of inheritance. > there's really only two things that are truly common: object identity, and some form of dynamic dispatch based on that. Everything else - inheritance, encapsulation etc - is optional. That's a broader definition than I had in mind, but I can see where you're coming from.

pmontra 7y ago

Sending a message to an Erlang / Elixir process to change its internal status (a GenServer) is not conceptually different than calling a method of an object. The big difference I see between Elixir and (example) Java or Ruby is that everything is an object in those languages but a big Elixir application has only a few GenServers, where keeping a state matters. Everything else is passed as argument, which by the way it's what a GenServer does internally with an endless tail recursion.