5 ms·
Imho types should make the programmer live easier, not more difficult. Looking at the first code, and at the second peace of code. Imho the second piece of cod
by TeeWEE 12y ago
Imho types should make the programmer live easier, not more difficult.
Looking at the first code, and at the second peace of code. Imho the second piece of code is easier to read, but it does lack validation logic & testing.
First of all, from a type-theory point of view, both Email and WebForm have the same type. (same signature).
Also from a theoretical point of view, i think a type should not have an instance if its not valid and "EmailAddress" of value "aasda" should not exists. However it is allowed in his types.
Also, I don't see how defining lots of very specific types such as FromAddress and ToAddress are really making live easier.
Something like this does the job, and is typesafe (in golang):
type EmailAddress string
type Email struct {
to EmailAddress
from EmailAddress
subject string
body string
}
func sendEmail(webForm string) err = {
email, err := validateEmailForm(form) # performs validation
if err {
return err
}
err := email_service.sendEmail(email)
if err {
return err
}
}
Tests will simply use the returnValue of sendMail to validate its inner working.
- xwowsersx 12y agoGood point. Having a separate FromAddress and ToAddress was probably overkill. You're right about the WebForm and Email having the same type. The form submission could probably just produce an Email directly. I don't know much about go. What is "err"?
- icebraining 12y agoGo follows the C tradition of returning errors instead of using exceptions. 'err' is a variable of type "error"[1], which should either be nil or have an error value. [1] http://golang.org/pkg/builtin/#error http://golang.org/pkg/builtin/#error
- xwowsersx 12y agoso the return type of this little program is "error" and nil if no error?
- icebraining 12y agoYes. It's either a value that implements the 'error' interface or nil.
- badbath 12y agoThat's nuts. All of your code now has to check if err != nil, etc. Furthermore, the sendEmail and validateEmailForm values are essentially ignored and used only for their possible error values. Why should I wrote my program as if the thing I'm concerned primarily with is errors? Much better to encode the failure into the type. You could have, for example, some function that returns Either[Error, SendEmailAction] where SendEmailAction is a function that, when called, will perform the effect of sending an email. Now I can deal with the happy path by mapping on the right-biased Either.
- ecopoesis 12y agoNot if you use Scala. With Scala, you'd just map or for comprehension over the result.
- icebraining 12y agoThis has been discussed in pretty much every golang thread here on HN :)
- TeeWEE 12y agoWhen I started go, i also thought it was nuts. And it indeed clutters your code a lot. But in the end, i like it. Golang is a really simple language, but all the simple concepts, and the lack of OOP, forces you to think more about your code. Also you are forced to think about error conditions. I'm still playing around with it. So i dont have a final opinion on go.
- dllthomas 12y agoHaving a separate FromAddress and ToAddress serves a somewhat similar purpose to labeled arguments. You can't mix them up, and you are informed if they change.