I personally don't like implicit this. You are very much passing a this instance around, as opposed to a class method. Also explicit this eliminates the problem, that you don't know if the variable is an instance variable or a global/from somewhere else.
People typically use some kind of naming convention for their member variables, e.g. mFoo, m_Foo, m_foo, foo_, etc., so that's not an issue. I find `foo_` much more concise than `this->foo`. Also note that you can use explicity this in C++ if you really want to.
object->ops->start(object)
Where not only is it explicit, but you need to specify the object twice (once to resolve the Vtable, and a second time to pass the object to the stateless C method implementation). object1->op->start(object2)
superclass->op->start(object)
I wrote about this concept[1] for my own understanding as well -- just tracing the an instance of the pattern through the tmux code.
[0] https://raw.githubusercontent.com/tmux/tmux/1536b7e206e51488... [1] https://blog.drnll.com/tmux-obj-oriented-commands
ryao•22h ago
This technique predates object oriented programming. It is called an abstract data type or data abstraction. A key difference between data abstraction and object oriented programming is that you can leave functions unimplemented in your abstract data type while OOP requires that the functions always be implemented.
The sanest way to have optional functions in object oriented programming that occurs to me would be to have an additional class for each optional function and inherit each one you implement alongside your base class via multiple inheritance. Then you would need to check at runtime whether the object is an instance of the additional class before using an optional function. With an abstract data type, you would just be do a simple NULL check to see if the function pointer is present before using it.
trws•17h ago
ryao•1h ago
In the Linux VFS for example, there are optimized functions for reading and writing, but if those are not implemented, a fallback to unoptimized functions is done at the call sites. Both sets are function pointers and you only need to implement one if I recall correctly.
f1shy•39m ago
naasking•25m ago
I think the "is/is not" question is not so clear. If you think of "is" as a whether there's a homomorphism, then it makes sense to say that it is OOP, but it can qualify as being something else too, ie. it's not an exclusionary relationaship.
mistrial9•1h ago
source- I wrote a windowing framework for MacOS using this pattern and others, in C with MetroWerks at the time.
ryao•1h ago
As for abstract data types, they originated in Lisp, which also predates object oriented programming.
pjmlp•1h ago
"AN ALGORITHMIC THEORY OF LANGUAGE", 1962
https://apps.dtic.mil/sti/tr/pdf/AD0296998.pdf
In this paper they are known as plexes, eventually ML and CLU will show similar approaches as well.
Only much latter would Lisps evolve from plain lists and cons cells.
pavlov•1h ago
It's sad that OOP was corrupted by the excessively class-centric C++ and Java design patterns.
mettamage•1h ago
pjmlp•1h ago
https://en.wikipedia.org/wiki/Portable_Distributed_Objects
pjmlp•1h ago
1718627440•1h ago
I would rather say that OOP is a formalization of predating patterns and paradigma.