[Proposal] about fut HOT 10 CLOSED

whoops, accidentally submitted. I was gonna put together a more comprehensive proposal for immutable classes along the lines of #9, but it's getting late 😅 I'll do it soon

from fut.

@jedwards1211 I'd be very interested in this. I tried to translate a Typescript interface into Cito, and, well, it wasn't pretty...

from fut.

Yeah, maybe this is what you meant, but I think that code won't work, since you can't assign to object storage with =. You would need a set method on each class that takes a readonly pointer to another instance and copies its values.

from fut.

@jedwards1211 I really just want something like structs; I read the other thread and I understand the concerns about structs and shared library compatability, but it sounded like you had something in mind to solve this?

from fut.

Possibly, I was just proposing an option to take the risk of library incompatibility on a class I'm confident I won't need to add or remove fields from.

But using a pointer to implementation would be another option that would enable more convenient code without that risk. The downside is it requires heap allocation. But maybe that's not so bad since all objects in most other languages besides C/C++ are allocated on the heap anyway...makes me curious if using shared pointers for everything in C++ performs better or worse than doing the same thing in a garbage collected language. I'm not sure that heap allocation in C++ can recycle objects as efficiently as sophisticated garbage collectors can?

from fut.

Also googling about smart pointers vs GC reminded me of something I had forgotten: smart pointers can't clean up cyclic garbage. You have to break the cycle manually for that memory to be freed. 😳

from fut.

I would definitely want to be able to use structs too for a case like yours, but nothing is easy in C/C++land... 😅

from fut.

I would definitely want to be able to use structs too for a case like yours, but nothing is easy in C/C++land... 😅

Well, that's exactly it, it WAS easy in C/C++ if you didn't have to worry about incompatilibility. I would have thought the risks were rather low here, but I suppose in the world of linux where libaries aren't bundled and get updated out-of-band, this could be a big hassle. I hope a solution can be found here, because trying to create union types is a huge pain in cito.

from fut.

I hope a solution can be found here, because trying to create union types is a huge pain in cito.

No idea what the solution should be for, as this is a closed, blank ticket. 😊

smart pointers can't clean up cyclic garbage. You have to break the cycle manually for that memory to be freed.

Typically one object owns another. The owned object typically doesn't delete the owner because that way it could delete self. So if the owned object needs a reference to the owner, it can be a regular reference which doesn't need to be broken manually when the owner is deallocated.

Very often you could have the owned object be an object storage field in the owner. Again, a cyclic reference poses no problem for deallocation.

Swift has the unowned keyword, with all object references being reference-counted by default.

from fut.

Typically one object owns another. The owned object typically doesn't delete the owner because that way it could delete self. So if the owned object needs a reference to the owner, it can be a regular reference which doesn't need to be broken manually when the owner is deallocated.

Yeah it's definitely the common case. I may end up writing code to operate on potentially cyclic graphs in some of my projects though, and if I hadn't learned it could leak memory, I bet I would have ended up naively using dynamic references between nodes. I think it would be worth warning devs who are only familiar with garbage-collected languages.

from fut.