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
(http://ieeexplore.ieee.org/document/564744/
<http://ieeexplore.ieee.org/document/564744/>) 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.vid...@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
> }
> }
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
