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.
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.
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.
> 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).
Are you storing the version as part of the object? If so, they’re no longer equal values regardless of identity. If not, what purpose is there in versioning the same value? Even if there is a purpose, are same-value-different-version objects not otherwise interchangeable unless/until some value change does occur?
Identity doesn't imply 'value' equality, that's the whole point of mutability! Conversely, two objects can have the same 'value' while having different identities. Values and objects are different beasts.
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.
It definitely is. I was just talking about the definition of "an object."
It separates the functionality from the object. Turns it into an external stimulus to change the state of an object.
I used this pattern, back in the 1990s, to make a C API behave like a C++ API. This was back when every compiler had a different stack convention, and the only one we could rely on, was C.
To be fair, I did have function pointers, in some of the objects, that acted as "poor man's vtables."
I know that the API was still in use, 25 years later.
It's possible that we are talking at cross purposes.
I think you might be arguing that the object itself does not include the set of functions/methods/operations that act on it, whereas I see them as another attribute of the class/type which is an attribute of the object.
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.
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.
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/..
In my experience, LLMs tend to perform better if you give them instructions before the data to be operated on. At least for the ~13b size models.
So,something like: Please count the number of words in the following sentence. "What is the number of words in the sentence coming before the next one?"
edit: Which might be an artifact of the training data always being in that kind of format.
The compiler may make optimization decisions based on the presence of UB so the code only needs to be present.
The compiler can't know that an arbitrary part of a function is unreachable if, for instance, that code path is controlled by a parameter or global state since that equates to solving the halting problem.
The undefined behavior can still affect code generation even though the program gets translated.
It's just that the generated code may not do exactly what you expect it to do because the presence of undefined behavior allowed the compiler to make assumptions which may surprise you.
DR 109 allows that a program may be strictly conforming even if some possible executions of the program invoke UB:
> A conforming implementation must not fail to translate a strictly conforming program simply because some possible execution of that program would result in undefined behavior.
This text specifically allows for the case that a program is strictly conforming even if there is a possible execution that invokes UB. If a program is strictly conforming, it must produce the correct behavior.
I would challenge you to show an example where GCC or Clang will break the correctness of a program on account of UB that is not reached during program execution.
Here is an example where GCC and Clang specifically respects the correctness of a program as long as it does not reach the UB: https://godbolt.org/z/befWah77W
On the flipside, this means the thin logic board that connects to the pins is in the host device, not in the cable.
Which means if you break it off, you need to replace the whole port, which might be difficult or expensive; instead of the (relatively) cheap cable.
I _love_ USB-C as a concept, but this alone makes, in my opinion, Lightning the superior physical connector.
And yes, I have had to replace / throw away entire devices because of a USB-C port breaking like this.
Sure, I should be less of a clumsy oaf around my electronics, but I also don't think "not bricking the entire device when extra force is applied to the port" is unreasonable design goal for a physical connector as universal as USB-C is.
Anecdotal evidence: I have had to replace a device because of a failed USB-C port, but I have never had to replace a device because of a failed Lightning port. I know, it's one data point, but there it is.
Was it on a Macbook? I think there could be some confounding factors if not -- there exist bottom of the barrel laptop manufacturers who'll somehow figure out a shitty way to implement a USB-C port. There doesn't exist a bottom of the barrel iPhone manufacturer. Apple does a good job of making sure all their components are mid-tier at least, I think. Maybe we could compare to third party lightning ports but they tend to be pretty rare.
The 2016 and 2017 MBPs had garbage USB-C ports which wore out their detents after like 10 insertions. The charge cable (or worse, data cable for an external hard drive) would fall out or lose connectivity with the slightest shift in position.
Interesting about the springs, I didn’t know that. In practice though, the opposite to everything you say seems to be true based on using many (many) of both connectors over the years. I’ve had a couple of disasters with USB-C ports breaking (on the device, not the cable), while I’ve never had anything go permanently wrong with Lightning sockets. Your point that it has delicate springs inside it sounds concerning but seems to be totally theoretical - you can see customer service staff in Apple stores frequently just whip out a SIM key or paperclip and waggle it about in a customer’s iPhone to clean it with total abandon. And I’ve always done this with mine, treating it very rough with metal paperclips, I’ve never worried about hurting the springs. And it has never, ever gone wrong for me. The evidence seems to be that Lightning is just much more resilient.
You say that cleaning out a USB-C port is safe, but I know it’s not, because of that little snap-off wafer inside, which has broken on me twice before. It’s not safe, I promise. Don’t do it unless you have a good warranty!
Thank you for the clarification. I didn't know that.
In my experience, cleaning the lightning port with the end of a paperclip was never an issue (dust from my pocket liked the spot; always helped when charging got unreliable).
It is slightly unfair to say there's barely an ecosystem. If all you've seen is Reykjanes between Keflavík and Reykjavík then sure it might look like a bleak, moss covered, rocky desert. But the thing is that different regions can vary quite drastically in their level of vegetation. You might have farmland on one side of a mountain but on the other side a vast sandy desert.
But, to be fair, if your measure of a fertile landscape is a forest then those are relatively few and far between. Personally I tend to feel a bit claustrophobic when there are trees boxing me in on all sides and I can't see the mountains. :)
Part of it is whether the code can be traced back to original AT&T code. Which would be true for e.g. BSD variants (which includes MacOS). https://i.redd.it/kgv4ckmz3zb51.jpg
You might be interested in these articles if you want to experiment with alternative approaches to the intrusive linked-list and are OK with using object pools. Very handy if you want to have cheap alloc/free and want good memory locality for updating the objects.
Thanks! I started with an intrusive linked list because I just wanted to get something working but replacing it with something else has been on my mind for the same reasons you mention.
reply