OK, apologies in advance for toes trodden on or sensibilities offended, but it
sounds like it’s time for my anti-optional-whining rant. :)
The really important thing about using Swift is that you *have to* learn to
change the way you think about dealing with nil values. It’s not quite
literally true (but it’s close) that in Obj-C you want to defer dealing with
nil values *as long as possible*, while in Swift you want to deal with nil
values *immediately*.
Putting this another way, the rule you should live and breathe is, “Don’t let
optionals propagate through your code.”
There are some exceptions to this principle. For example, if you’re parsing a
name string for first, middle and last name, and the middle name is optional,
you might well choose to carry the middle name forward as `String?` (an
optional string). But you should typically start by writing your code as if
there are no optionals, and eliminate/resolve them as they appear.
For example, it’s a really bad idea to write code like this:
let url = URL(string: “some string”)
/* … things involving `url?` … */
It’s much better to deal with the optional right away. For example:
let url = URL(string: “some string”)! // no more optional, when your
URL string is known good
Or, if your string can be genuinely an invalid URL string:
guard let url = URL(string: “some string”) else { /* deal with the
error condition and … */; return } // or break or whatever
Not only does it take practice to remember to do things this way round, but
also I *guarantee* you that it will throw your tried and trusted Obj-C code
design patterns into chaos. You must, I’m afraid, suffer through this, long
enough until your brain “flips” and starts pouring out code that is Swift-like
in Swift, not Obj-C-like in Swift.
It actually took me about a year, back in the Swift 2 days, to figure out that
I needed to write Swift like Swift, not like Obj-C, and a year or two to get
comfortable with that. But I was slow and stupid: it shouldn’t really need to
take that long. It just takes a willingness to spend time writing and rewriting
sections of code until you get to that “Aha!” moment. That’s when you will
become a Swift fan.
There’s nothing truly wrong with Obj-C as a language, and there’s no need to
diss it in order to appreciate Swift. But the two have different coding
patterns, and if you want to use Swift professionally you will need to learn
and practice its natural coding patterns. (If you don’t, that’s fine too!)
People have been offering opinions all day of what Swift is like, compared to
other languages. One point that doesn’t get mentioned is that Swift was
intended to fill the hole where (so to speak) Obj-C 3.0 or 4.0 would go. A lot
of its syntax and philosophy is intended to do what we did comfortably in
Obj-C, but with more efficiency in the task of actual code writing. It’s
evolved away from Obj-C in some fairly weird ways, but I’ll happily defend my
belief that it *is* a more efficient way to write code.
I loved Obj-C for 15 years (or so). Now I write Swift almost exclusively.
/end rant
> On Oct 14, 2019, at 20:44 , Laurent Daudelin via Cocoa-dev
> <cocoa-dev@lists.apple.com> wrote:
>
> I’ve been wondering the same thing. I thought that maybe because I was biased
> toward Obj-C. But if it wasn’t for the editor, damn, I don’t know how many
> times I would have to go back to unwrap one of those optionals. Are people
> supposed to know instinctively when you unwrap with “?” and when you do with
> “!”? I’m not there yet, even though I’ve been doing almost a year of Swift so
> far...
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
