4 ms·

Interesting choice of NewEmail() over the more idiomatic email.New().

dkuntz2 13y ago
In Go isn't `email.NewEmail()` more idiomatic? To be fair, you could write: e = &email.Email{ [fields and values] } The only thing NewEmail does is give you a pointer to an Email.
- ihsw 13y ago
  Not necessarily: https://www.google.com/search?q=golang+%22func+New(%22+site%3Agolang.org%2Fpkg https://www.google.com/search?q=golang+%22func+New(%22+site%...
  - noselasd 13y ago
    There's a lot of NewXXX too. The convention is if a package exports only one single type, call it New(...), otherwise call it NewXXX(...)
ihsw 13y ago
In actuality it would be `email.NewEmail()` -- the lack of namespace specificity is due to the code examples already being part of the package. The issue with a simple `New()` 'constructor' is that there is ambiguity as to what struct it's creating.
- staunch 13y ago
  package main import ( "log" "net/smtp" "github.com/jordan-wright/email" ) func main() { e := email.NewEmail() e.From = "Jordan Wright <test@gmail.com>" e.To = []string{"test@example.com"} e.Bcc = []string{"test_bcc@example.com"} e.Cc = []string{"test_cc@example.com"} e.Subject = "Awesome Subject" e.Text = "Text Body is, of course, supported!" e.HTML = "<h1>Fancy HTML is supported, too!</h1>" err := e.Send("smtp.gmail.com:587", smtp.PlainAuth("", "x@gmail.com", "pw", "smtp.gmail.com")) if err != nil { log.Fatal(err) } }
- mratzloff 13y ago
  There are dozens of instances of New() in the standard library.
jwcrux 13y ago
Good point - when developing the package, I was referencing these [1][2] documents which showed the use of NewObject() instead of New(). I figured since I provide more than one possible struct (both Email and Attachment), the use of NewEmail would provide consistency. However, now that you mention it, I suppose it wouldn't have hurt, and the meaning would have been fairly clear. Oh well - live and learn, at this point, I'm doing my best not to break backwards compatibility if I don't have to. Thanks for the heads up! [1] http://golang.org/doc/effective_go.html#composite_literals http://golang.org/doc/effective_go.html#composite_literals [2] https://sites.google.com/site/gopatterns/object-oriented/constructors https://sites.google.com/site/gopatterns/object-oriented/con...
- dkuntz2 13y ago
  Like ihsw said, in Go you probably should leave it as `NewEmail` because `New` is ambiguous.
- DrJokepu 13y ago
  If your package exports a single type only, New is more appropriate, if it exports multiple types, you should use NewObject: http://golang.org/doc/effective_go.html#names http://golang.org/doc/effective_go.html#names
  - mseepgood 13y ago
    Many packages have a dominant type and a couple of satellite types. If the package name is the same as or similar to the name of the dominant type, 'New' can be appropriate as well.
    - DrJokepu 13y ago
      Right. As long it’s super obvious which type New creates, it’s perfectly fine.
- scott_s 13y ago
  Stuart Feldman, from "The Art of Unix Programming", on why makefiles must use tabs: "Why the tab in column 1? Yacc was new, Lex was brand new. I hadn't tried either, so I figured this would be a good excuse to learn. After getting myself snarled up with my first stab at Lex, I just did something simple with the pattern newline-tab. It worked, it stayed. And then a few weeks later I had a user population of about a dozen, most of them friends, and I didn't want to screw up my embedded base. The rest, sadly, is history."

In Go isn't `email.NewEmail()` more idiomatic? To be fair, you could write: e = &email.Email{ [fields and values] } The only thing NewEmail does is give you a pointer to an Email.

ihsw 13y ago
Not necessarily: https://www.google.com/search?q=golang+%22func+New(%22+site%3Agolang.org%2Fpkg https://www.google.com/search?q=golang+%22func+New(%22+site%...
- noselasd 13y ago
  There's a lot of NewXXX too. The convention is if a package exports only one single type, call it New(...), otherwise call it NewXXX(...)

ihsw 13y ago

In actuality it would be `email.NewEmail()` -- the lack of namespace specificity is due to the code examples already being part of the package. The issue with a simple `New()` 'constructor' is that there is ambiguity as to what struct it's creating.

staunch 13y ago
package main import ( "log" "net/smtp" "github.com/jordan-wright/email" ) func main() { e := email.NewEmail() e.From = "Jordan Wright <test@gmail.com>" e.To = []string{"test@example.com"} e.Bcc = []string{"test_bcc@example.com"} e.Cc = []string{"test_cc@example.com"} e.Subject = "Awesome Subject" e.Text = "Text Body is, of course, supported!" e.HTML = "<h1>Fancy HTML is supported, too!</h1>" err := e.Send("smtp.gmail.com:587", smtp.PlainAuth("", "x@gmail.com", "pw", "smtp.gmail.com")) if err != nil { log.Fatal(err) } }
mratzloff 13y ago
There are dozens of instances of New() in the standard library.

jwcrux 13y ago

Good point - when developing the package, I was referencing these [1][2] documents which showed the use of NewObject() instead of New(). I figured since I provide more than one possible struct (both Email and Attachment), the use of NewEmail would provide consistency. However, now that you mention it, I suppose it wouldn't have hurt, and the meaning would have been fairly clear. Oh well - live and learn, at this point, I'm doing my best not to break backwards compatibility if I don't have to. Thanks for the heads up! [1] http://golang.org/doc/effective_go.html#composite_literals http://golang.org/doc/effective_go.html#composite_literals [2] https://sites.google.com/site/gopatterns/object-oriented/constructors https://sites.google.com/site/gopatterns/object-oriented/con...

dkuntz2 13y ago
Like ihsw said, in Go you probably should leave it as `NewEmail` because `New` is ambiguous.
DrJokepu 13y ago
If your package exports a single type only, New is more appropriate, if it exports multiple types, you should use NewObject: http://golang.org/doc/effective_go.html#names http://golang.org/doc/effective_go.html#names
- mseepgood 13y ago
  Many packages have a dominant type and a couple of satellite types. If the package name is the same as or similar to the name of the dominant type, 'New' can be appropriate as well.
  - DrJokepu 13y ago
    Right. As long it’s super obvious which type New creates, it’s perfectly fine.
scott_s 13y ago
Stuart Feldman, from "The Art of Unix Programming", on why makefiles must use tabs: "Why the tab in column 1? Yacc was new, Lex was brand new. I hadn't tried either, so I figured this would be a good excuse to learn. After getting myself snarled up with my first stab at Lex, I just did something simple with the pattern newline-tab. It worked, it stayed. And then a few weeks later I had a user population of about a dozen, most of them friends, and I didn't want to screw up my embedded base. The rest, sadly, is history."