4 ms·
It is true though! Consider a simple example where you have two classes, with one depending on the other. As a best practice, I'd like to inject one class int
by turdprincess 3y ago
It is true though! Consider a simple example where you have two classes, with one depending on the other. As a best practice, I'd like to inject one class into the other's constructor, so I could do some unit testing.
Here is the Swift code:
class Dependency1 {
}
class Object1 {
private let dependency: Dependency1
init(dependency: Dependency1 = Dependency1()) {
self.dependency = dependency
}
}
And the Objective C equivalent:
@interface Dependency1 : NSObject
@end
@implementation Dependency1
@end
@interface Object1 : NSObject
- (instancetype)initWithDependency:(Dependency1 *)dependency;
- (instancetype)init;
@end
@interface Object1()
@property (nonatomic, strong, readonly) Dependency1 *dependency;
@end
@implementation Object1
- (instancetype)initWithDependency:(Dependency1 *)dependency {
self = [super init];
if (self) {
_dependency = dependecy;
}
return self;
}
- (instancetype)init
{
return [self initWithDependency:[[Dependency1 alloc] init]];
}
@end
Thats 9 lines of code in Swift and 31 lines of code in Objective C. If I have to type 3 times more code every time I want to break up big class into a few smaller ones, I am going to be much less likely to do it.
In other words, the sheer verbosity of Objective C will make even the most disciplined developer start cutting corners to reduce effort, which ultimately leads to codebases which are messier, harder to test and less flexible.
And finally, looking at the example above, is it really true that Objective C is easier to learn and understand than Swift? The code forces you to learn:
* What is an NSObject?
* How to create a private category on an class
* What does "alloc init" do, and why is it different than "new"?
* What is the difference between `self.dependency` and `_dependency`, and why does one let me change a "readonly" property?
* Why would `super init` return nil, and what does that mean?
For sure Swift also has its share of nuance, but I feel like the Objective C nuance is just baggage, while the Swift nuance opens the door to a richer feature set.
[edited] updated code for correctness
- lapcat 3y agoThat ObjC code doesn't make sense, if you look at the logic of it. You said in a previous edit (you keep editing your comments endlessly) that you generated it with ChatGPT. Not to mention, your Swift code doesn't even compile. Maybe try actually writing code in Xcode. And maybe write your comments in a text editor and finish them before you post...
- turdprincess 3y agoCurious, which part of that Objective C code doesn't make sense to you? What its doing is: * Creating a header and implementation for each object * Using a private category to keep a variable private * Implementing multiple constructors because you can't have default variables. Can you suggest a more concise way to accomplish any of the above?
- lapcat 3y ago> Curious, which part of that Objective C code doesn't make sense to you? For one thing, the initWithDependency: method ignores its argument! (Also it's unclear why it needs 2 blank lines just to jack up your line of code count.) Does the class even need to declare -init? That's 6 more lines of code added for no apparent reason. In general, everyone acknowledges that Swift is more terse and Objective-C is more verbose, so if your main complaint is just the number of lines of code, that's not particularly interesting.
- turdprincess 3y ago> For one thing, the initWithDependency: method ignores its argument! Yes good, callout, I edited the code to fix this mistake > Does the class even need to declare -init? You are basically making my point. Its totally normal engineer's reaction to look to erase this boilerplate by removing the dependency injection, or using a singleton. Overtime, those decisions make the codebase worse. In Swift, you simply don't have to make this tradeoff. > if your main complaint is just the number of lines of code, that's not particularly interesting Verbosity alone is a major problem - why would it be a good idea to use a language which takes more time to read and write to accomplish your goal? It's a disadvantage. Another issue is a lack of expressiveness and a dumber type system. Stuff like union types and optionals all allow you to express your system in a more airtight way. The lack of these features leads to, you guessed it, more boilerplate in ObjC. Ultimately, noone is arguing that you should rewrite your existing ObjC in Swift - if your code exists and works, leave it alone. But the article is arguing that Objective C is a "better" language for writing iOS apps, which doesn't make any sense for all the reasons above.