Your comments about type safety and convenience are valid. So your right it has additional value to have optionals in a language.
But to answer your question: create a class StringIntegerUnion and subclasses StringFromStringIntergerUnion and IntegerFromStringIntegerUnion.
That will make it completely type safe and absolutely clear to read and will give no runtime errors.
In general I think it's not a good idea to think in terms of unions made of basic types, most code should not need that.
In a JVM language, creating extra classes leads to more classes needed by the classloader and more classes allocated to the heap (there are no structs/value types at the JVM level presently). I know Swift does have structs which makes this more of a moot point for that language. I realize in an object-oriented language you need to create classes to get work done, but with Java 8 lambdas there will hopefully be a lot less classes needed and several class-heavy design patterns will hopefully be made obsolete. The same is true of generics when it was introduced in Java 5. There is a time for creating custom classes, but sometimes you want to let the type system take some of the burden away from hand-coding a multitude of classes.
In a JVM language, creating extra classes leads to more classes needed by the classloader and more classes allocated to the heap (there are no structs/value types at the JVM level presently). I know Swift does have structs which makes this more of a moot point for that language. I realize in an object-oriented language you need to create classes to get work done, but with Java 8 lambdas there will hopefully be a lot less classes needed and several class-heavy design patterns will hopefully be made obsolete. The same is true of generics when it was introduced in Java 5. There is a time for creating custom classes, but sometimes you want to let the type system take some of the burden away from hand-coding a multitude of classes.
Let me ask you a question. Can I do this with Swift enums (as it's not clear from the Swift language guide):
enum StringOrInteger
case String
case Integer
Do I need to define my own case classes within the enum, or can I wrap an enum around everything?
What I'm really asking is can I do the equivalent of String|Integer easily in Swift via an enum.
And, again, String|Integer is a contrived example. I'm asking about doing this for any classes otherwise unrelated in the class hierarchy?
Ok, I see your point. From what I read just now it's not the type itself your defining, but a member (name) and its associated type.
But this is what you need in most cases I guess and almost the same as you would like to see (only a bit less abstract).
But I might not see the whole picture, so maybe someone else with more knowledge about this can comment?
Edit: so in Swift you have to write:
enum StringOrInteger {
case StringType(String)
case IntType(Int)
}
to define your optional type and write:
switch optional value {
case .StringType(let s): println(s)
case .IntType(let i): println(\(i)
}
2) Expressing a function that could return one of two types. A good example is a String or some sort of Error type on a function that does some sort of computation. If the computation succeeds, return a String, otherwise, an Error.
Ummm... in Swift the best way to do that would be to return a tuple.
func myFunc() -> (s:String?, e:NSError?) { ... }
let result = myFunc()
if let s = result.s {
...
} else if let e = result.e {
...
}
You'd have to assign to a variable and test out the union result type anyway, so the unwrapping logic is basically a wash. It's also a much cleaner implementation than the standard iOS error handling tactic of doing:
To me, this is one of those cases where you can be so caught up with a single way of doing things that you fail to embrace the language, work with it, and find out what it can do for you instead.
I agree that exceptions can be abused but I think eliminating them takes away a useful tool that should be applied sparingly. For instance, exceptions are useful for assertions. That is, if you're expecting a List to contain something and it doesn't, and you know is is due to a programming error, making such an assertion is useful, especially early in he development cycle. With Swift, you'll need to check every single possibility with conditional logic. With the lack of union types in the language, and the consequent use of case types, this will be especially jarring.
I disagree. I have never seen a design using exceptions that did not cover for a basically poor architecture. In the 20 years I have been dealing with code that relies on exceptions, i have not yet seen a situation where they presented a better design than a properly defined interface and API to modules and classes.
This is why I now consider exceptions to be among the first things I look for in a language NOT having.
The idea behind exceptions seems excellent, but in practice it is hardly used and makes code difficult to read and comprehend (cause and effect isn't located near each other in the code and you still have to handle the exception in a sensible way and that can be difficult).
So removing exception processing makes it easier to handle the exception in a reasonable way?
Quote:
So I understand the language developers (at Apple) left it out to reduce language complexity.
Yes, doing exception handling properly in a language is very difficult. Apple's engineers punted on this. That is the crux of it.
It has been a long underlined point by Apple that exceptions are to be avoided at all costs in Objective-C and Cocoa.
Okay, Apple has a poor subsystem for handling exceptions. Maybe they should work on fixing that...
Quote:
Exceptions simply marked an unrecoverable state, a last chance effort to grab information before the app was killed.
What about those exceptions that are recoverable?
I love the "exceptions should never be used as a control structure" argument. First of all, if exceptions are being used as control structures, maybe the language's designers should have created a workable control structure in its place. Let me give you one example where "exceptions as control structures" works really well -- in a recursive-descent compiler. Raising an exception (say syntax error in a deeply recursive expression parse) that pops up to the main statement level of the parse is a *very good* way to handle this situation. We don't care that this is frightfully slow (in theory, errors are not the common case so the fact that it takes 10x-100x longer to process them doesn't really matter). Of course, if there *was* a reasonable control structure to let you unwind calls and other recursive operations, that would be cool too. There are some really crazy things you can do with closures to simulate this, but it's nowhere near as clean and easy to read and understand as exception handling.
Quote:
There are inherit (no pun intended) issues surrounding memory and inheritance and exceptions.
Apple's language designers: "Oooooh, this is hard. Let's not do it."
Quote:
The NSError pattern has always been the preferred way to handle these situations. A lot of Java and C++ developers glossed over this.
Preferred by who?
Quote:
NSException wasn't added until later in Cocoa's Foundation after Apple adopted it. It became a religious war between devs, so this time around, Apple just did away with exceptions entirely.
IOW, "we're on the side of no exceptions, so we'll declare victory by simply doing away with exceptions entirely. Because it *was* a religious war, it's pretty clear that some people think differently from Apple's language designers.
Here's a great idea-- put exceptions in. Let developers *choose* how they want to handle it. If some people want to code every possibility into their code and not use exceptions (the Pascal approach), let them. Provide the NSError mechanism. If people want to use that, more power to them. Provide exceptions (as part of the language, not as an add-on). If people want to use that, more power to them. Why should the language designers make these kinds of decisions?
I say if you want to offer Daniel constructive criticism, contact him privately, instead of throwing things out for everyone to see.
I am really ambivalent on DED's fanboism. However, if he is going to post an article with his opinions here he should be able to handle the criticisms that follow in the posts. That is why we're allowed to post here.
Due to its level of expressiveness, type inference, sugar syntax and other "typing shortcuts" Swift is hard to read and therefore hard for code reviews. It's quite obvious the language is optimised for small devices and tailored to indie developers.
Wow, this is a big matter of opinion.
Personally, I don't think that Swift is anywhere near ready for prime time but (lack of) readability is nowhere near on my list of complaints. Swift is far more readable to me than is Obj-C. I *really* like the direction Swift took from Obj-C (well, except for exceptions and the craziness associated with characters and strings).
I am really ambivalent on DED's fanboism. However, if he is going to post an article with his opinions here he should be able to handle the criticisms that follow in the posts. That is why we're allowed to post here.
And you don't see a difference between certain posters coming onto every thread for a DED article to dump on him, opposed to other articles will people come to have actual discussions about the article?
Elimination of exceptions is the biggest plus to Swift. I have seen exception designs so hideous that it is sad.
Just because some people are clueless when it comes to using exceptions is not a good reason to remove them from the language. Trust me, the people who made those hideous "exception designs" will find something else to make hideous when they no longer have exceptions available to them.
And you don't see a difference between certain posters coming onto every thread for a DED article to dump on him, opposed to other articles will people come to have actual discussions about the article?
No. Just saying that if you're going to post an opinion piece on a blog, you're going to have to be ready to expect this kind of response. One could make the same argument, btw, about people sucking up to DED all the time.
And you don't see a difference between certain posters coming onto every thread for a DED article to dump on him, opposed to other articles will people come to have actual discussions about the article?
Quoted post said: "if you want to offer Daniel constructive criticism", which is a bit different from a dump on.
Due to its level of expressiveness, type inference, sugar syntax and other "typing shortcuts" Swift is hard to read and therefore hard for code reviews. It's quite obvious the language is optimised for small devices and tailored to indie developers.
Wow, this is a big matter of opinion. Personally, I don't think that Swift is anywhere near ready for prime time but (lack of) readability is nowhere near on my list of complaints. Swift is far more readable to me than is Obj-C. I *really* like the direction Swift took from Obj-C (well, except for exceptions and the craziness associated with characters and strings).
"Personally, I don't think that Swift is anywhere near ready for prime time"
Swift has evolved (maybe has been incrementally exposed is a better phrase) since it's release at WWDC 8 months ago. It's gone from being unusable to being relatively stable for a 1.0 product.
I think that a lot of the problems are with Xcode and tools rather than with the language, itself. Both Swift and Xcode seem to get better with each beta release.
I understand that professional developers do not have the luxury of continuously spending time to monitor the progress of the new language and tools -- rather, as time and interest permits, they periodically update themselves to see if the latest implementations meet muster.
A few of honest questions:
Why, is Swift not ready for prime time?
Aside from exceptions and string craziness -- what's wrong with Swift (say top 5)?
How current is your experience with Swift -- have you experimented with the latest beta?
Okay, Apple has a poor subsystem for handling exceptions. Maybe they should work on fixing that...
What about those exceptions that are recoverable?
I love the "exceptions should never be used as a control structure" argument. First of all, if exceptions are being used as control structures, maybe the language's designers should have created a workable control structure in its place. Let me give you one example where "exceptions as control structures" works really well -- in a recursive-descent compiler. Raising an exception (say syntax error in a deeply recursive expression parse) that pops up to the main statement level of the parse is a *very good* way to handle this situation. We don't care that this is frightfully slow (in theory, errors are not the common case so the fact that it takes 10x-100x longer to process them doesn't really matter). Of course, if there *was* a reasonable control structure to let you unwind calls and other recursive operations, that would be cool too. There are some really crazy things you can do with closures to simulate this, but it's nowhere near as clean and easy to read and understand as exception handling.
Apple's language designers: "Oooooh, this is hard. Let's not do it."
Preferred by who?
IOW, "we're on the side of no exceptions, so we'll declare victory by simply doing away with exceptions entirely. Because it *was* a religious war, it's pretty clear that some people think differently from Apple's language designers.
Here's a great idea-- put exceptions in. Let developers *choose* how they want to handle it. If some people want to code every possibility into their code and not use exceptions (the Pascal approach), let them. Provide the NSError mechanism. If people want to use that, more power to them. Provide exceptions (as part of the language, not as an add-on). If people want to use that, more power to them. Why should the language designers make these kinds of decisions?
If there is one thing I've learned in the 13 years of writing Apple software, is to follow Apple's conventions or it most likely will burn you later on. Apple clearly prefers the NSError design pattern (and even has ARC optimizations surrounding it). They clearly call out that the Cocoa frameworks respond ill towards exceptions being thrown, exceptions that are uncaught will take down a program (it can be easy to miss if they are abused), and there are memory issues with subclasses that may add resources that need to be released before an exception is thrown.
I'm not sure what the Swift approach is to unwinding the stack yet, but I'm sure it will be addressed soon if it hasn't been already. For the time being, there is still NSException that can be used with Swift, but I wouldn't rely on it for very long. The bridging between obj-c and swift will probably come with less support as Apple moves towards a Swift world. End of the day, Swift is not Objective-C, it is not Java and it is not C++. Why not let the author decide what we use instead?
Just because some people are clueless when it comes to using exceptions is not a good reason to remove them from the language. Trust me, the people who made those hideous "exception designs" will find something else to make hideous when they no longer have exceptions available to them.
Write your own programing language and you, can be the King and have exceptions built in.
If the new watch (iDevice) is being release in April 2015. Many very talented programers have already finished writing some very good software for it using Swift and Metal?, I believe the programers that use the new tools, will be ahead of the curve and are going to do very well in a new marketplace. Isn't that a good thing?
Wow, this is a big matter of opinion.
Personally, I don't think that Swift is anywhere near ready for prime time but (lack of) readability is nowhere near on my list of complaints. Swift is far more readable to me than is Obj-C. I *really* like the direction Swift took from Obj-C (well, except for exceptions and the craziness associated with characters and strings).
I find Objective-C far more legible and self-documenting.
If the new watch (iDevice) is being release in April 2015. Many very talented programers have already finished writing some very good software for it using Swift and Metal?, I believe the programers that use the new tools, will be ahead of the curve and are going to do very well in a new marketplace. Isn't that a good thing?
Comments
Your comments about type safety and convenience are valid. So your right it has additional value to have optionals in a language.
But to answer your question: create a class StringIntegerUnion and subclasses StringFromStringIntergerUnion and IntegerFromStringIntegerUnion.
That will make it completely type safe and absolutely clear to read and will give no runtime errors.
In general I think it's not a good idea to think in terms of unions made of basic types, most code should not need that.
In a JVM language, creating extra classes leads to more classes needed by the classloader and more classes allocated to the heap (there are no structs/value types at the JVM level presently). I know Swift does have structs which makes this more of a moot point for that language. I realize in an object-oriented language you need to create classes to get work done, but with Java 8 lambdas there will hopefully be a lot less classes needed and several class-heavy design patterns will hopefully be made obsolete. The same is true of generics when it was introduced in Java 5. There is a time for creating custom classes, but sometimes you want to let the type system take some of the burden away from hand-coding a multitude of classes.I understand this and agree completely.
I fail to see the difference (did you take 'associated values' in account)?
Can you give an example what you can't do with Swift enums (with associated values) that you can do with optionals?
Let me ask you a question. Can I do this with Swift enums (as it's not clear from the Swift language guide):enum StringOrInteger
case String
case Integer
Do I need to define my own case classes within the enum, or can I wrap an enum around everything?
What I'm really asking is can I do the equivalent of String|Integer easily in Swift via an enum.
And, again, String|Integer is a contrived example. I'm asking about doing this for any classes otherwise unrelated in the class hierarchy?
Ok, I see your point. From what I read just now it's not the type itself your defining, but a member (name) and its associated type.
But this is what you need in most cases I guess and almost the same as you would like to see (only a bit less abstract).
But I might not see the whole picture, so maybe someone else with more knowledge about this can comment?
Edit: so in Swift you have to write:
enum StringOrInteger {
case StringType(String)
case IntType(Int)
}
to define your optional type and write:
switch optional value {
case .StringType(let s): println(s)
case .IntType(let i): println(\(i)
}
to select it.
Ummm... in Swift the best way to do that would be to return a tuple.
func myFunc() -> (s:String?, e:NSError?) { ... }
let result = myFunc()
if let s = result.s {
...
} else if let e = result.e {
...
}
You'd have to assign to a variable and test out the union result type anyway, so the unwrapping logic is basically a wash. It's also a much cleaner implementation than the standard iOS error handling tactic of doing:
NSError *error;
NSString *result = [myFunc: something error:&error].
To me, this is one of those cases where you can be so caught up with a single way of doing things that you fail to embrace the language, work with it, and find out what it can do for you instead.
I disagree. I have never seen a design using exceptions that did not cover for a basically poor architecture. In the 20 years I have been dealing with code that relies on exceptions, i have not yet seen a situation where they presented a better design than a properly defined interface and API to modules and classes.
This is why I now consider exceptions to be among the first things I look for in a language NOT having.
The idea behind exceptions seems excellent, but in practice it is hardly used and makes code difficult to read and comprehend (cause and effect isn't located near each other in the code and you still have to handle the exception in a sensible way and that can be difficult).
So removing exception processing makes it easier to handle the exception in a reasonable way?
Yes, doing exception handling properly in a language is very difficult. Apple's engineers punted on this. That is the crux of it.
Okay, Apple has a poor subsystem for handling exceptions. Maybe they should work on fixing that...
What about those exceptions that are recoverable?
I love the "exceptions should never be used as a control structure" argument. First of all, if exceptions are being used as control structures, maybe the language's designers should have created a workable control structure in its place. Let me give you one example where "exceptions as control structures" works really well -- in a recursive-descent compiler. Raising an exception (say syntax error in a deeply recursive expression parse) that pops up to the main statement level of the parse is a *very good* way to handle this situation. We don't care that this is frightfully slow (in theory, errors are not the common case so the fact that it takes 10x-100x longer to process them doesn't really matter). Of course, if there *was* a reasonable control structure to let you unwind calls and other recursive operations, that would be cool too. There are some really crazy things you can do with closures to simulate this, but it's nowhere near as clean and easy to read and understand as exception handling.
Apple's language designers: "Oooooh, this is hard. Let's not do it."
Preferred by who?
IOW, "we're on the side of no exceptions, so we'll declare victory by simply doing away with exceptions entirely. Because it *was* a religious war, it's pretty clear that some people think differently from Apple's language designers.
Here's a great idea-- put exceptions in. Let developers *choose* how they want to handle it. If some people want to code every possibility into their code and not use exceptions (the Pascal approach), let them. Provide the NSError mechanism. If people want to use that, more power to them. Provide exceptions (as part of the language, not as an add-on). If people want to use that, more power to them. Why should the language designers make these kinds of decisions?
I say if you want to offer Daniel constructive criticism, contact him privately, instead of throwing things out for everyone to see.
I am really ambivalent on DED's fanboism. However, if he is going to post an article with his opinions here he should be able to handle the criticisms that follow in the posts. That is why we're allowed to post here.
Due to its level of expressiveness, type inference, sugar syntax and other "typing shortcuts" Swift is hard to read and therefore hard for code reviews. It's quite obvious the language is optimised for small devices and tailored to indie developers.
Wow, this is a big matter of opinion.
Personally, I don't think that Swift is anywhere near ready for prime time but (lack of) readability is nowhere near on my list of complaints. Swift is far more readable to me than is Obj-C. I *really* like the direction Swift took from Obj-C (well, except for exceptions and the craziness associated with characters and strings).
And you don't see a difference between certain posters coming onto every thread for a DED article to dump on him, opposed to other articles will people come to have actual discussions about the article?
Elimination of exceptions is the biggest plus to Swift. I have seen exception designs so hideous that it is sad.
Just because some people are clueless when it comes to using exceptions is not a good reason to remove them from the language. Trust me, the people who made those hideous "exception designs" will find something else to make hideous when they no longer have exceptions available to them.
And you don't see a difference between certain posters coming onto every thread for a DED article to dump on him, opposed to other articles will people come to have actual discussions about the article?
No. Just saying that if you're going to post an opinion piece on a blog, you're going to have to be ready to expect this kind of response. One could make the same argument, btw, about people sucking up to DED all the time.
And you don't see a difference between certain posters coming onto every thread for a DED article to dump on him, opposed to other articles will people come to have actual discussions about the article?
Quoted post said: "if you want to offer Daniel constructive criticism", which is a bit different from a dump on.
"Personally, I don't think that Swift is anywhere near ready for prime time"
Swift has evolved (maybe has been incrementally exposed is a better phrase) since it's release at WWDC 8 months ago. It's gone from being unusable to being relatively stable for a 1.0 product.
I think that a lot of the problems are with Xcode and tools rather than with the language, itself. Both Swift and Xcode seem to get better with each beta release.
I understand that professional developers do not have the luxury of continuously spending time to monitor the progress of the new language and tools -- rather, as time and interest permits, they periodically update themselves to see if the latest implementations meet muster.
A few of honest questions:
Okay, Apple has a poor subsystem for handling exceptions. Maybe they should work on fixing that...
What about those exceptions that are recoverable?
I love the "exceptions should never be used as a control structure" argument. First of all, if exceptions are being used as control structures, maybe the language's designers should have created a workable control structure in its place. Let me give you one example where "exceptions as control structures" works really well -- in a recursive-descent compiler. Raising an exception (say syntax error in a deeply recursive expression parse) that pops up to the main statement level of the parse is a *very good* way to handle this situation. We don't care that this is frightfully slow (in theory, errors are not the common case so the fact that it takes 10x-100x longer to process them doesn't really matter). Of course, if there *was* a reasonable control structure to let you unwind calls and other recursive operations, that would be cool too. There are some really crazy things you can do with closures to simulate this, but it's nowhere near as clean and easy to read and understand as exception handling.
Apple's language designers: "Oooooh, this is hard. Let's not do it."
Preferred by who?
IOW, "we're on the side of no exceptions, so we'll declare victory by simply doing away with exceptions entirely. Because it *was* a religious war, it's pretty clear that some people think differently from Apple's language designers.
Here's a great idea-- put exceptions in. Let developers *choose* how they want to handle it. If some people want to code every possibility into their code and not use exceptions (the Pascal approach), let them. Provide the NSError mechanism. If people want to use that, more power to them. Provide exceptions (as part of the language, not as an add-on). If people want to use that, more power to them. Why should the language designers make these kinds of decisions?
If there is one thing I've learned in the 13 years of writing Apple software, is to follow Apple's conventions or it most likely will burn you later on. Apple clearly prefers the NSError design pattern (and even has ARC optimizations surrounding it). They clearly call out that the Cocoa frameworks respond ill towards exceptions being thrown, exceptions that are uncaught will take down a program (it can be easy to miss if they are abused), and there are memory issues with subclasses that may add resources that need to be released before an exception is thrown.
I'm not sure what the Swift approach is to unwinding the stack yet, but I'm sure it will be addressed soon if it hasn't been already. For the time being, there is still NSException that can be used with Swift, but I wouldn't rely on it for very long. The bridging between obj-c and swift will probably come with less support as Apple moves towards a Swift world. End of the day, Swift is not Objective-C, it is not Java and it is not C++. Why not let the author decide what we use instead?
https://devforums.apple.com/message/970961#970961
https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/Exceptions/Exceptions.html#//apple_ref/doc/uid/10000012-BAJGFBFB
Just because some people are clueless when it comes to using exceptions is not a good reason to remove them from the language. Trust me, the people who made those hideous "exception designs" will find something else to make hideous when they no longer have exceptions available to them.
Write your own programing language and you, can be the King and have exceptions built in.
If the new watch (iDevice) is being release in April 2015. Many very talented programers have already finished writing some very good software for it using Swift and Metal?, I believe the programers that use the new tools, will be ahead of the curve and are going to do very well in a new marketplace. Isn't that a good thing?
I find Objective-C far more legible and self-documenting.
If the new watch (iDevice) is being release in April 2015. Many very talented programers have already finished writing some very good software for it using Swift and Metal?, I believe the programers that use the new tools, will be ahead of the curve and are going to do very well in a new marketplace. Isn't that a good thing?
Wait, What? Does ?Watch have a Metal chip in it?