[asgeir]

It's not a requirement, but an immutable object has fewer uses than a mutable one.

Functions/methods/actions/operations are just different names for the operations which mutate the state of the object. So, I would argue that they are a necessary attribute of mutable objects.

[eyelidlessness]

Object identity effectively implies mutability. Without that implication, two objects of the same structured value being non-equal doesn’t mean anything (and would probably be better classified as a mistake).

Another way to look at it is that property setters (or whatever mechanism is used to directly mutate an object’s sub-data) is not meaningfully different from a method doing the same. You could even call it syntax sugar for the same.

[odipar]

My take is that identity doesn't imply mutability, if you version objects. It could well be that your are looking at an old version of an object, using its unique identity combined with its version (number).

Objects refer to other objects using their (immutable) identity. In turn, resolving identities to objects requires (version) scope which can be in the past or present.

[kaba0]

This point is actually emphasized strongly by the CS giant, Guy Steele himself.

[jghn]

OOP schemes like CLOS, Dylan, S4, and others keep Objects and Actions separate. This is similar to Haskell type classes.

[ChrisMarshallNY]

Maybe, but mutability does not require inbuilt operations.

I have often used data-only objects, and passed them to fixed-context functions.

It's a cheap way to get OO behavior, in non-OO languages.

[asgeir]

I would still classify that as object oriented behavior.

You have a class/type of objects, and you have a set of functions or operations which are associated with (loosely or tightly) and operate on that type of object.

For example, I would say that file descriptors are a handle to a type of object. They encapsulate the thing that they represent (file, DRM buffer, eventfd, whatever), and some of the functions that operate on them are polymorphic. For example, read, close, ioctl, etc., don't care if the file descriptor is a file, a queue, or whatever.

You use syscalls to interact with file descriptors, but they are just as much object handles.

[knome]

Yeah, object orientation isn't just a language feature, it's a pattern for structuring interaction with data.

And as for object orientation being less useful in immutable languages, I see it used plenty.

Erlang and haskell both define dictionary types that return new copies of the dictionary on what would normally be mutating function calls. The dictionary's gory details are hidden behind the object's mask, leaving the user free to ignore if it is a hash into an array of arrays, as many dicts used to be and as allows sharing most of the entries between copies of the dict until resizing, or maybe it's actually a balanced tree or just an a-list.

The outer code doesn't need to know because you create and manipulate the dictionary abstractly through helper functions, be they attached via the language or simply exposed while leaving the implementation opaque.

Object orientation will also be used to hide the implementations of files, sockets, and other abstract resources.

Many interfaces throughout the linux kernel use a plain C form of object orientation, a language which is definitely not object oriented on its own, filling out an 'interface' structure with functions to be used for objects originating from a particular area, allowing the kernel to interact abstractly with filesystems via the function pointers in the struct, for example.

[localhost8000]

We could say that mutability (or having functions/methods/etc) is part of the object’s identity.

[ChrisMarshallNY]

I consider identity to be an object that is exclusively itself, and knows what it is. You can treat it in an opaque manner, and its own identity will dictate how external stimulus works on it.

[trgn]

So weird this is getting down voted. Immutable objects would just be structs with sugar. It's mutability that gives you the power to keep a reference to an object, but have it keep up with the operational lifecucle of your app/process/..