4 ms·

The author seems to not know Swift very well, because this behaviour was ported over to Swift in a very nice, type safe manner: In Swift, you can call methods

The author seems to not know Swift very well, because this behaviour was ported over to Swift in a very nice, type safe manner: In Swift, you can call methods on Optional values, and they evaluate to null or the actual value. So the authors example: if (dict.containsObjectForKey[@"a"]) { ... } Would look like this: if dict?.contains("a") { ... } The `?` tells Swift to only call `contains` if `dict` is not null. The return value of this call would then be another optional. This second point is the improvement over Objective-C. There, you would not know whether the return value of `dict.containsObjectForKey` is a potential null value. This, in turn, would crash the app if you'd try to use this return value to, say index into an array or perform math on it. In Swift, the compiler yells at you to remind you that this value can be null. So, really, Swift has the same benefits, but better.

mojuba 4y ago
Yes, but Objective-C is even more permissive than that. For example, [object method] where method is supposed to return an int, will return 0 if object is nil. This is of course a double-edged sword: it's too easy to make a mistake in your logic, but also you can use it to your advantage if you know what you are doing. The advantage really being just writing slightly less, i.e. eliminating extra if's. All this, however, didn't save Objective-C from being over all a very verbose language. At least from my experience of rewriting from ObjC to Swift, the latter can make your code half the size of the original and as an added bonus will make it so much safer too. This is why Objective-C is objectively and hopelessly dead now.
- Cloudef 4y ago
  In swift you do mymethod?.call(...) Where method can be nil and it has the same effect. Similarly object?.something has the same effect. Use exclamation mark instead of question mark, to make swift runtime panic if the object or method is nil. Obj-c is objectively worse in every way and easy way to improve bugs in your code that go unnoticed for long time. Another cool thing is that you can use ?? At end of expression that can return nil to decide what to do if nil is returned (for example return something else). So swift actually reduces the amount of ifs required.
  - mojuba 4y ago
    > In swift you do mymethod?.call(...) Where method can be nil and it has the same effect. No, it doesn't. (You probably meant object?.mymethod()). If mymethod returns int, then in Swift the result of this expression is strictly Optional<Int>, whereas in Objective-C it's Int defaulting to zero if object is nil. The implications in terms of safety are significant.
    - Cloudef 4y ago
      I did mention object?.mymethod as well, method?.call is needed if you want to call on nullable method itself in a safe way.
    - setr 4y ago
      DefaultZero = Object?.mymethod() ?? 0; Optional-null + null-coalescing is strictly more flexible than obj-c’s behavior, while more sanely defined, with very minimal syntax
- terhechte 4y ago
  double fraction = 1.0 / [object method]; huzzah :)
happytoexplain 4y ago
Note that it would actually be (also changing to an array to make your abbreviation of the author's example make more sense): `if arr?.contains("a") == true { ... }` or `if arr?.contains("a") ?? false { ... }` or `if (arr ?? []).contains("a") { ... }` or `if let arr= arr, arr.contains("a") { ... }` or `if arr!= nil, arr!.contains("a") { ... }` Optional<Bool> will not automatically unwrap where Bool is expected (since the compiler would have to assume nil is falsey, which is the kind of mushy shenanigans Swift explicitly denies).

mojuba 4y ago

Yes, but Objective-C is even more permissive than that. For example, [object method] where method is supposed to return an int, will return 0 if object is nil. This is of course a double-edged sword: it's too easy to make a mistake in your logic, but also you can use it to your advantage if you know what you are doing. The advantage really being just writing slightly less, i.e. eliminating extra if's. All this, however, didn't save Objective-C from being over all a very verbose language. At least from my experience of rewriting from ObjC to Swift, the latter can make your code half the size of the original and as an added bonus will make it so much safer too. This is why Objective-C is objectively and hopelessly dead now.

Cloudef 4y ago
In swift you do mymethod?.call(...) Where method can be nil and it has the same effect. Similarly object?.something has the same effect. Use exclamation mark instead of question mark, to make swift runtime panic if the object or method is nil. Obj-c is objectively worse in every way and easy way to improve bugs in your code that go unnoticed for long time. Another cool thing is that you can use ?? At end of expression that can return nil to decide what to do if nil is returned (for example return something else). So swift actually reduces the amount of ifs required.
- mojuba 4y ago
  > In swift you do mymethod?.call(...) Where method can be nil and it has the same effect. No, it doesn't. (You probably meant object?.mymethod()). If mymethod returns int, then in Swift the result of this expression is strictly Optional<Int>, whereas in Objective-C it's Int defaulting to zero if object is nil. The implications in terms of safety are significant.
  - Cloudef 4y ago
    I did mention object?.mymethod as well, method?.call is needed if you want to call on nullable method itself in a safe way.
  - setr 4y ago
    DefaultZero = Object?.mymethod() ?? 0; Optional-null + null-coalescing is strictly more flexible than obj-c’s behavior, while more sanely defined, with very minimal syntax
terhechte 4y ago
double fraction = 1.0 / [object method]; huzzah :)

happytoexplain 4y ago

Note that it would actually be (also changing to an array to make your abbreviation of the author's example make more sense): `if arr?.contains("a") == true { ... }` or `if arr?.contains("a") ?? false { ... }` or `if (arr ?? []).contains("a") { ... }` or `if let arr= arr, arr.contains("a") { ... }` or `if arr!= nil, arr!.contains("a") { ... }` Optional<Bool> will not automatically unwrap where Bool is expected (since the compiler would have to assume nil is falsey, which is the kind of mushy shenanigans Swift explicitly denies).