5 ms·
> How would you go about implementing activeUser.Delete()? I guess you would have to replace the object. If we're talking about a functional style then yes, `U
by inglor 11y ago
> How would you go about implementing activeUser.Delete()? I guess you would have to replace the object.
If we're talking about a functional style then yes, `User`s would be immutable object, changing them would return a new user. Doing `activeUser.Delete()` returns a new deleted user, doing `deletedUser.Undelete()` returns a new active user. I might go as far as creating the user as a value type (struct) but that's a bit unorthodox.
- mannykannot 11y ago> Doing `activeUser.Delete()` returns a new deleted user... But don't you now risk having two mutually contradictory objects representing one user?
- eropple 11y agoIt's a rare application where the gap between creating a new immutable object (aside: this is really annoyingly hard to write this quickly and cleanly in C#, it is my one serious beef with the language--looking forward to record classes!) and the GC of the old one matters materially. If they're not being shared across multiple requests, for example, it's pretty rare that the momentary superposition of deleted and not-deleted would be risky.
- Retra 11y agoOnly if you don't do it atomically. And while you can't guarantee atomic deletes, you can enforce them using the type system. Think of the following code: if (n != null) { n.do_something() } What happens if n gets deleted after the null check, but before the method invocation? So you are already assuming that you can do certain things atomically, even if, in theory, some external agent can write on your data. You manage that by protecting your data (with asynchronous tools or immutability), or by statically verifying your code.