Hmm, not sure, if I’ve heard of it. I’m guessing, we’re not talking about simply drawing a UML class diagram…? Is it for figuring out which object will have to clean up which other objects, in non-GCed languages?
Yes, pretty much like UML diagrams. Who is responsible for allocating memory and freeing it.
Languages like Swift, Objective-C, C++ have features that mean you don’t need to do this by hand. But you have to tell the compiler if you want to keep and object around and who owns it.
Ah, interesting. I went from garbage-collected languages where thinking about ownership might be useful for keeping complexity low and occasionally comes up when you manage lists of objects, but ultimately isn’t needed, to Rust where well-defined ownership is enforced by the language.
So, I wasn’t aware that ownership is even as concrete of a thing in other languages…
Oh you need this in garbage collected languages too, once you run into memory use issues. GC languages are notorious for being wasteful with memory, even when working correctly.
Not if you never get your application into production…
I wish this was as much of a joke as I’m pretending. It’s so common for software projects to get cancelled that lots of tooling differences are just in terms of how long they let you not deal with long-term problems and how violently they do then explode into your face.
For most of the development lifecycle of a GCed project, you’re gonna ignore memory usage. And if you’re lucky, it can be ‘solved’ by just plonking down a thiccer piece of hardware…
OOP also has object ownership hierarchy structures. Which object owns which other object, is a question always worth answering.
Hmm, not sure, if I’ve heard of it. I’m guessing, we’re not talking about simply drawing a UML class diagram…? Is it for figuring out which object will have to clean up which other objects, in non-GCed languages?
Yes, pretty much like UML diagrams. Who is responsible for allocating memory and freeing it.
Languages like Swift, Objective-C, C++ have features that mean you don’t need to do this by hand. But you have to tell the compiler if you want to keep and object around and who owns it.
See this article on Objective-C to see the different ways to manage memory this language supports.
Ah, interesting. I went from garbage-collected languages where thinking about ownership might be useful for keeping complexity low and occasionally comes up when you manage lists of objects, but ultimately isn’t needed, to Rust where well-defined ownership is enforced by the language.
So, I wasn’t aware that ownership is even as concrete of a thing in other languages…
Oh you need this in garbage collected languages too, once you run into memory use issues. GC languages are notorious for being wasteful with memory, even when working correctly.
Not if you never get your application into production…
I wish this was as much of a joke as I’m pretending. It’s so common for software projects to get cancelled that lots of tooling differences are just in terms of how long they let you not deal with long-term problems and how violently they do then explode into your face.
For most of the development lifecycle of a GCed project, you’re gonna ignore memory usage. And if you’re lucky, it can be ‘solved’ by just plonking down a thiccer piece of hardware…
Great points. Especially putting in more memory can get you very far.
Database optimization? Nah, just put in 1 TB of RAM to keep the whole DB in memory at all times.