I am almost not sure if this is a joke or not. That is an incredibly complicated looking hieroglyphic to dispatch a bit of code. I do this:
- (void)prepareForSegue:(UIStoryboardSegue *)segue sender:(id)sender {
NSString* message = [NSString stringWithFormat: @"prepareSeque%@To%@:",(segue.identifier ? segue.identifier : @""), [segue.destinationViewController class]];
SEL method = NSSelectorFromString(message);
if([self respondsToSelector:method])
{
[self performSelector:method withObject:segue.destinationViewController];
}
}
// Assume segue identifier was NextStep and we are going to a NextViewController
-(void)prepareSequeNextStepToNextViewController:(NextViewController*)vc
{
// do specific work in a small focused method instead of buried in a giant ugly switch statement
}
Burying all that logic in a bunch of control statements just obfuscates intent. Now, you may argue my prepareForSegue is a little bit ugly and I would agree with you - but I write that once, stick it on UIViewController as an extension method, and never look at it again, instead going off the naming convention - much like the responder chain works.
I keep hearing the same justifications over and over. "Compiler can't check that", "pattern matching", "powerful enums", "protection from nil", "faster execution", "exhaustively checked switch statements" etc.... I do not value any of that stuff and it all goes out the window once your program beings consuming data from outside. It doesn't make my programs more powerful, more expressive, more robust, or better. It does slow me down a lot trying to satisfy a bunch of constraints that are, frankly, irrelevant to my problem domain and what it does instead is refocus my attention from the problem domain into the implementation domain unnecessarily.
The conventional wisdom is that switch statements are an anti pattern in the presence of OO features. They're brittle and basically they're goto's. Polymorphism is to be preferred. I thought we settled that in the 90s.
It is becoming more and more clear that the ideals of Swift are nothing like the Smalltalk ideals that gave us Cocoa (and Cocoa is a very elegant framework loaded with beautiful design patterns that have served us very well - well enough to let little Apple eat Microsoft's lunch). Swift is a lot closer to the ideals of C++ and ML and they are a terrible fit on top of a Smalltalk inspired framework. Write Swift if you must - but stop screwing up the Apple app scene with it.
Seriously, I'm out. I'd just like to ask the Apple people to stop dumping cruft into the Objective C header files. I don't care about nullable annotations or the fake generics cruft. Objective C is based on Smalltalk. This direction is anathema to the Smalltalk ideals that underly the existing Cocoa system. Nils don't matter and generics are nonsense in a dynamically typed world. I mean, have any of you even used a book on Smalltalk as a doorstop much less read one?
Basically, you're killing the golden goose. Like when WebObjects was ported to Java. It didn't survive the change from dynamic language to more rigid type constrained Java language. It just died.
Cocoa won't either.
I'm signing off this list. Swift is about the opposite of what I need in a programming language. It will not scale to the enterprise any better than C++ did (clue - it didn't - I was there) and the embedded world has already had working Smalltalk implementations all the way down to fpga's (Revisiting Smalltalk-80 blocks: a logic generator for FPGAs | IEEE Conference Publication | IEEE Xplore) for over 20 years so I'm completely unpersuaded by the efficiency arguments or the compiler checked "correctness" arguments. Software is never correct, never done, never perfect. Best to have an environment that can deal with that.
Oh and uh - stop pushing Swift as the future. 9/10 jobs doing iOS now demand Swift. Thanks for that. And by thanks - I mean screw you, Apple. State of iOS development today is a disaster.
Out.
···
On Jan 11, 2017, at 00:04, André Videla <andre.videla@gmail.com> wrote:
func prepareForSegue(segue: UIStoryboardSegue, sender: Any?) {
Switch (segue.identifier, segue.destination, sender) {
Case ("Segue"?, let vc as FirstVC, .some(.enumType(let value)) ): // prepare the vc
... // other segues
}
}