3 ms·
Counterpoint: I read many of these "handles" articles several years ago, and tried them in my code, and it was something of a mistake. The key problem is that
by chubot 3y ago
Counterpoint: I read many of these "handles" articles several years ago, and tried them in my code, and it was something of a mistake. The key problem is that they punt on MEMORY SAFETY
An arena assumes trivial ownership -- every object is owned by the arena.
But real world programs don't all have trivial ownership, e.g. a shell or a build system.
Probably the best use case for it is a high performance game, where many objects are scoped to either (1) level load time or (2) drawing a single frame. You basically have a few discrete kinds of lifetimes.
But most software is not like that. If you over-apply this pattern, you will have memory safety bugs.
- throwawaymaths 3y agoyou'd be surprised how far you can get with this. Handles are basically how things like Erlang VM (and IIRC javascript VMs) work.
- meheleventyone 3y agoDisagree, you can easily add validation to handle access with generations. The classic example in games is reusing pooled game elements where their lifetimes are very dependent on gameplay. For example reusing enemies from a pool of them where their lifetime is dependent on when they get spawned and destroyed which can be chaotic. Here handles with generations preserve memory safety by preventing access to stale data.