4 ms·
I think this is much less to do with performance and more to do with safety. If anything can be nil, NPEs are a fact of life. If you're forced to annotate for t
by MBlume 12y ago
I think this is much less to do with performance and more to do with safety. If anything can be nil, NPEs are a fact of life. If you're forced to annotate for the compiler which values can be nil, and then forced to handle the nil case when you consume them, the problem disappears.
- hrktb 12y agoI don't think the problem disappears so easily. It puts a signifiant burden on the programmer (on the top of my head, if I have a set of 20 properties in an object, all optionals, I'll have to unwrap them all, even if I can guarantee by knowledge of the data that they're not nil), it will still throw an error if a value became nil after the test, and there is still the implicit unwrapping system that would cause runtime exceptions on nil values. I see the value of the safeguard, but it seems cumbersome as a language level rule; I hated The boilerplating in Java, and it goes a bit in the same direction. I'm not sure I like the bureaucracy of explicitely testing every single variable that could be nillable to use them, but I'd love to be proven wrong.
- Glide 12y agoI was looking through the programming language referenced that was published and the patterns that it uses to deal with Optionals isn't that bad. Having the question mark helps a great deal as a mental check when comparing syntaxes. In my opinion, having that as a language rule will probably force people to design their classes to have things set at initialization more often than not.
- hrktb 12y ago> In my opinion, having that as a language rule will probably force people to design their classes to have things set at initialization more often than not. Good point. There are some interesting work in javascript, like Om, to mainly use immutable objects, it could go in the same direction.