[methodover]

Ding ding ding. The entire article hangs on “imply”.

The question of where data is stored for an object is far less important than how to access data in a data structure. Like, the whole reason the data structure is designed the way it is, is to access it in particular ways.

[Jach]

Part of this reminds me of discussing the differences between "data structure" and "algorithm". Sometimes it's hard to separate them, especially since many algorithms don't need anything more elaborate than "get" and "put" into some opaque data store. Add requirements on the data store that make it less opaque (can't "put" for instance, making it immutable) and your algorithms change. Change your algorithms and you might want a more specific data store interface too ("get most recently put"). Performance requirements are probably the biggest driver for changing both, especially when it comes to actually structuring the data store and its interface on top of some physically realized medium. If we had infinite computing power our software would look a lot different and probably more mathematical.

[narag]

Careful. The author is not using "data structure" with the standard Computer Science meaning, but as C language struct. Standard data structures were actually the equivalent to current classes and were associated with a set of functions.

If you bother to take a look to C APIs, you'll find the familiar "handle" parameter, equivalent to the "this" or "self" of OO languages. Setting aside all the philosophical mumbo jumbo, OO is syntactic sugar over those interfaces.

[roelschroeven]

> The author is not using "data structure" with the standard Computer Science meaning, but as C language struct.

The text would have been a lot clearer if that would have been more explicit from the beginning!