Maybe try actually writing code in Xcode.
And maybe write your comments in a text editor and finish them before you post...
* 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?
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.
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.
You made me look at two classes, totally out of context, that didn't even work with the first code presented. And I have absolutely no clue how they would be used, so I can't properly evaluate them.
The boilerplate is fine as far as I'm concerned; you were the one who was obsessed with the number of lines of code, and it seemed to me you were exaggerating them for no apparent reason, so that's why I was looking to remove some.
> why would it be a good idea to use a language which takes more time to read
I don't agree with that. A more verbose language can be easier to read.
> and write
It's premature optimization. Personally, I don't spend the majority of my time typing in code. I spend a lot of time thinking, designing, running, testing, debugging, etc. The time spent typing in the code is not a big worry for me. If Swift is faster to type, but the compiler is a lot slower, and the damn debugger doesn't even work, that doesn't seem like a good tradeoff to me.
> But the article is arguing that Objective C is a "better" language for writing iOS apps
I was actually arguing that Objective-C is a better language for writing UIKit iOS apps, which is a more specific claim, given that the underlying frameworks are themselves Objective-C, for the reasons explained in the blog post.