Hacker News new | ask | show | jobs
by mamcx 4236 days ago
So, if I design a language, how design it well? I suspect is easy to kill all values (ints, str, etc) and arrays/list of it. But how know what is a "don't own any heap-allocated subobject" (sorry to ask if this is obvious, I have not deep experience in this matters)?

Is not circular references the real problem? And what when the object reference a resource like a file/handle/database/etc?

So, could be good idea to mark objects like this (maybe in separated areas of memory?):

Instant kill: Ints, Strs, Bools, Array of all of this

Safe destructors: If it hold a resource (file, handle)

But don't know what to do for objects like Customer.Orders = List<Orders>[Order1.Customer]

1 comments

This is not necessarily a language-level decision (except for GC, it helps in this case spread out the deallocations when using incremental GC).

You just have to be aware what happens in the destructor when you manually free an object. Libraries can make knowing this more difficult.

I guess you could build incremental alloc/release pools (even with reuse) or such things but it comes down to being aware of the problem as described and avoiding cascaded releases.

And to be honest this is not a super common problem but it can happen.