My rule of thumb is that I won’t consider an object unless I need some dynamic dispatch. That is, about, the only valuable feature objects have (and in most languages they come at a grave price).
this is object oriented programming, it’s just oop without pleasant syntactic and compiler support from the language. mixer_set_volume(m, 0.8) calls a function that takes a mixer object and sets some internal property on it. m->set_volume(0.8) takes a mixer object and calls a function that sets some internal property on it. you could argue that the “object oriented” bit refers to the fact that you start with “takes a mixer object that” rather than “calls a function that”, but given that the transformation between the two is mostly mechanical, i have a hard time saying that they are two different programming paradigms.
If this is OOP then OOP is a meaningless concept, roughly equivalent to people saying C is a functional language because it has function pointers. This is writing modular code, which happens in any sane program. What is not here, however, is a dispatch table, which is fairly fundamental to every language’s implementation of OOP. An object is a tuple containing an opaque state and a dispatch table, and this modular programming does not use the dispatch table.
In common lisp, we would call it (set-volume m 0.8) and if we make set-volumegeneric, then we can make several implementations for set-volume, including one that responds to a mixer. This is called object oriented even though the object does not contain a dispatch table (but the function does!)
Method dispatch / polymorphism / “virtual methods” is probably the least contested features under the OOP umbrella. Most FP advocates actually like it.
Where opinions differ is usually about overall code structure, i.e. do we structure our code around objects, or do we structure it around other building blocks (functions, modules).
Well, if you go back to the roots of OOP, its paradigm is actually quite different from what we associate with OOP nowadays (ie, C++/Java/.NET style OOP). In “pure” OO languages, such as Smalltalk or Self, objects are defined as “entities that communicate through the exchange of messages”, which is close to what we would call an Actor today. OOP is a fundamentally different approach to application architecture, and in true OO you focus on the exchanges/interactions between objects, as much as you focus on the data that they encapsulate. A method call is, in essence, sending a message to the target object. It’s up to the object (or the compiler) to decide what to do with the message, and how to answer it.
Just a gentle reminder that I took some pains at the last OOPSLA to try to
remind everyone that Smalltalk is not only NOT its syntax or the class
library, it is not even about classes. I’m sorry that I long ago coined the
term “objects” for this topic because it gets many people to focus on the
lesser idea.
The big idea is “messaging” – that is what the kernal of Smalltalk/Squeak
is all about (and it’s something that was never quite completed in our
Xerox PARC phase). The Japanese have a small word – ma – for “that which
is in between” – perhaps the nearest English equivalent is “interstitial”.
The key in making great and growable systems is much more to design how its
modules communicate rather than what their internal properties and
behaviors should be.
You’re absolutely right in that the OO described in this post is not what was intended with Smalltalk. However, the world has no landed on Smalltalk for their OOP, so if this author missed the point, you’ve missed the last 20 years.
Just because people are doing something different and calling it the same thing doesn’t mean the people who originated and named the concept in the first place lose their priority over the definition.
Yes, it absolutely does. Both definitions can exist, but you can’t really wave your hand and post a link and say the last 20 years hasn’t happened how it’s happened.
The definition is really beside the point anyway…what I’m saying is that the features the OP is complaining about are not what was interesting about OO in the first place, and that interesting stuff (messaging) isn’t nearly as trivial to reimplement using simple transformations like those in the article.
In other words, he’s accurately demonstrating that we should move beyond the obsession with some of the trivial features of OOP—but that is not at all the same as demonstrating that all of OOP, in its full definition, is trivial.
My rule of thumb is that I won’t consider an object unless I need some dynamic dispatch. That is, about, the only valuable feature objects have (and in most languages they come at a grave price).
Interfaces in Go and row polymorphism are great too.
How are you saying that interfaces in Go are different from dynamic dispatch?
this is object oriented programming, it’s just oop without pleasant syntactic and compiler support from the language.
mixer_set_volume(m, 0.8)calls a function that takes a mixer object and sets some internal property on it.m->set_volume(0.8)takes a mixer object and calls a function that sets some internal property on it. you could argue that the “object oriented” bit refers to the fact that you start with “takes a mixer object that” rather than “calls a function that”, but given that the transformation between the two is mostly mechanical, i have a hard time saying that they are two different programming paradigms.If this is OOP then OOP is a meaningless concept, roughly equivalent to people saying C is a functional language because it has function pointers. This is writing modular code, which happens in any sane program. What is not here, however, is a dispatch table, which is fairly fundamental to every language’s implementation of OOP. An object is a tuple containing an opaque state and a dispatch table, and this modular programming does not use the dispatch table.
In common lisp, we would call it
(set-volume m 0.8)and if we makeset-volumegeneric, then we can make several implementations forset-volume, including one that responds to amixer. This is called object oriented even though the object does not contain a dispatch table (but the function does!)on reflection, you’re right - absent some form of run-time type dispatch, this is modules rather than OOP.
Method dispatch / polymorphism / “virtual methods” is probably the least contested features under the OOP umbrella. Most FP advocates actually like it. Where opinions differ is usually about overall code structure, i.e. do we structure our code around objects, or do we structure it around other building blocks (functions, modules).
Well, if you go back to the roots of OOP, its paradigm is actually quite different from what we associate with OOP nowadays (ie, C++/Java/.NET style OOP). In “pure” OO languages, such as Smalltalk or Self, objects are defined as “entities that communicate through the exchange of messages”, which is close to what we would call an Actor today. OOP is a fundamentally different approach to application architecture, and in true OO you focus on the exchanges/interactions between objects, as much as you focus on the data that they encapsulate. A method call is, in essence, sending a message to the target object. It’s up to the object (or the compiler) to decide what to do with the message, and how to answer it.
Exactly, this is how you do OOP in C. And internally C++ (And probably many other languages) generates code something like this.
This person missed the point. To quote Alan Kay (who should know): “The big idea is ‘messaging’”.
http://lists.squeakfoundation.org/pipermail/squeak-dev/1998-October/017019.html
You’re absolutely right in that the OO described in this post is not what was intended with Smalltalk. However, the world has no landed on Smalltalk for their OOP, so if this author missed the point, you’ve missed the last 20 years.
Just because people are doing something different and calling it the same thing doesn’t mean the people who originated and named the concept in the first place lose their priority over the definition.
Yes, it absolutely does. Both definitions can exist, but you can’t really wave your hand and post a link and say the last 20 years hasn’t happened how it’s happened.
The definition is really beside the point anyway…what I’m saying is that the features the OP is complaining about are not what was interesting about OO in the first place, and that interesting stuff (messaging) isn’t nearly as trivial to reimplement using simple transformations like those in the article.
In other words, he’s accurately demonstrating that we should move beyond the obsession with some of the trivial features of OOP—but that is not at all the same as demonstrating that all of OOP, in its full definition, is trivial.
[edit, hit post accidentally]