[narag]

the existence of `List` implies that e.g. `sort` exists?

The existence of List implies that operations must exist to insert an element in a list, access to elements in a list, find out the size of the list, etc.

Edit: BTW 'implies' is the the magic word in the text. It's what creates all the appearance of meaning. Try to replace it what something else. Now I remember why I disliked Plato so much.

[gugagore]

I thought about using `[]`or `indexOf` as examples of operations, but my question still remains: what is implicit about it? It's part of the public interface of `List`.

Not at all like the private members of an object, which I think was the analogy being made.

[lalaithion]

Those aren't implicit because the "public interface" is the Object List, not the Data Structure List.

    struct list {
      float node;
      struct list *next;
    }

Above is the data structure; it implies operations. Below is an interface (class, in the article); it implies data.

    #define LIST_H
    
    float index(struct list *ls, int i);
    int find(struct list *ls, float x);
    void sort(struct list *ls);

[breischl]

I think the point is that the data structure implies that there must be some operations to create and examine it. If there is no operation to create it, how did it come to exist? If there is no operation to examine it, then how do you know it's there at all? To go all Zen koan on it: if a data structure cannot be examined or changed, then is it really there at all?

That said I don't think that any particular set of operations is implied. A data structure will be more suitable for some operations than others, but it won't really require anything in particular.

[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!