3 ms·
Not having closures as members is not better than having them with a simple rule that says "don't serialize". Your reasoning is alien and strange.
by nurettin 9y ago
Not having closures as members is not better than having them with a simple rule that says "don't serialize". Your reasoning is alien and strange.
- yorwba 9y agoA "simple rule" that's not programmatically enforced is just a convention, and conventions are too easily ignored. I'd be ok with a type-system based solution that distinguishes serializable and non-serializable types, but silently writing nondeserializable data is just asking for trouble down the road. This language in particular is built around having value semantics for everything (e.g. writing to a database and reading back is guaranteed to result in an indistinguishable value); and that enables nice features like persisting the complete application state on disk, deterministic replay of logs and so on. I think for the goals of this language, disallowing closures as data is a reasonable choice.
- nurettin 9y agoIt makes sense to enforce non-serialization using attributes, but then, closures should never be serialized, so you are where you started.