I'm just going to reply to one part with an example of the problem.
> I think this is somewhat incorrect. You should never just be type-casting your inputs. (In fact, I think it should ideally be impossible to do so without the compiler generating really big flashing warnings saying "THIS IS DANGEROUS!"). The static verification here will prevent you from doing silly things, and should ideally force you to do input validation at the location of input, instead of blindly casting things to the type it needs.
I did not say anything about type-casting inputs. I said coercing values into a given type. The naïve approach can be to type-cast, the other way is to write the code for the coercion process.
// some collection we are holding the values in for some reason
NSMutableArray *inputValues = [[NSMutableArray alloc] init];
NSString *someInputValue = // probably read from user input or a file
NSInteger value = [someInputValue integerValue];
BOOL validInput = YES;
if (value == 0) { // we need to check that there really is a value of 0...
NSString *trimmed = [someInputValue stringByTrimmingCharactersInSet:NSCharacterSet.whitespaceCharacterSet];
NSString *trimmed0 = [trimmed stringByTrimmingCharactersInSet:[NSCharacterSet characterSetWithCharactersInString:@"0"]];
if (trimmed0.length != 0) {
// oops, actually had an error... handle it
validInput = NO;
}
}
if (validInput) {
[inputValues addObject:@(value)];
}
Of all of the places where could have had errors along the way, the last `[inputValues addObject:@(value)];` doesn't really concern me that much.
Also, the compiler doesn't help me get things correct... the only thing it would have helped me do is make sure I put an integer into the array, not that I had the right values in the array. Had I not known that `integerValue` returns `0` in its error cases, I would have not known that I need to write some additional code to verify the string value was indeed a zero.
And generics only helps you when you have collections of identical types. Storing arrays of plist entries, for instance, requires you to revert back to `AnyObject` (or similar).
Generics can be helpful, if it's done well. However, even in .NET's generic system, with all the limitations and constraints it put in, there are many times where it still gets in the way.
I'm tired of fighting with my tools just to get the job done. Currently, Swift makes me fight a heck of a lot more then I want to or need to just to make the compiler happy. The end code I write is the same both ways, but the Swift code has a lot more annotations and is a lot less flexible.
> I think this is somewhat incorrect. You should never just be type-casting your inputs. (In fact, I think it should ideally be impossible to do so without the compiler generating really big flashing warnings saying "THIS IS DANGEROUS!"). The static verification here will prevent you from doing silly things, and should ideally force you to do input validation at the location of input, instead of blindly casting things to the type it needs.
I did not say anything about type-casting inputs. I said coercing values into a given type. The naïve approach can be to type-cast, the other way is to write the code for the coercion process.
Of all of the places where could have had errors along the way, the last `[inputValues addObject:@(value)];` doesn't really concern me that much.Also, the compiler doesn't help me get things correct... the only thing it would have helped me do is make sure I put an integer into the array, not that I had the right values in the array. Had I not known that `integerValue` returns `0` in its error cases, I would have not known that I need to write some additional code to verify the string value was indeed a zero.
And generics only helps you when you have collections of identical types. Storing arrays of plist entries, for instance, requires you to revert back to `AnyObject` (or similar).
Generics can be helpful, if it's done well. However, even in .NET's generic system, with all the limitations and constraints it put in, there are many times where it still gets in the way.
I'm tired of fighting with my tools just to get the job done. Currently, Swift makes me fight a heck of a lot more then I want to or need to just to make the compiler happy. The end code I write is the same both ways, but the Swift code has a lot more annotations and is a lot less flexible.