3 ms·

I found the notion of "Optionals" surprising and a bit hard to handle at first. In Objective C it was really easy to lazily allow values to be nil and still do

by hrktb 12y ago

I found the notion of "Optionals" surprising and a bit hard to handle at first. In Objective C it was really easy to lazily allow values to be nil and still do things on them, so it's a bit of a departure. Thinking about it a bit longer, is it because of the clear distinction between non nullable values ans optionals that the compiler can optimise the code so much more ? (I am thinking about the xx times faster than Objective C claims)

AlexanderDhoore 12y ago
This might increase performance, but I'm pretty sure it's mostly there for safety. It forces the programmer to check for nil. It's like Haskell's "maybe" type.
- cdmckay 12y ago
  Or Scala's Option or Java 8's new Optional (http://docs.oracle.com/javase/8/docs/api/java/util/Optional.html http://docs.oracle.com/javase/8/docs/api/java/util/Optional....)
jcromartie 12y ago
It's because it has a grown-up type system. This is a great step in the right direction. ObjC's treatment of nil was handy for a long time, but a basic Option type is far better to show the intent of code.
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 ago
  I 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 ago
    I 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.

by hrktb 12y ago

AlexanderDhoore 12y ago

This might increase performance, but I'm pretty sure it's mostly there for safety. It forces the programmer to check for nil. It's like Haskell's "maybe" type.

cdmckay 12y ago
Or Scala's Option or Java 8's new Optional (http://docs.oracle.com/javase/8/docs/api/java/util/Optional.html http://docs.oracle.com/javase/8/docs/api/java/util/Optional....)

jcromartie 12y ago

It's because it has a grown-up type system. This is a great step in the right direction. ObjC's treatment of nil was handy for a long time, but a basic Option type is far better to show the intent of code.

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 ago
I 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 ago
  I 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.