Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Request: MailboxAddress constructor for email part only #267

Closed
nvivo opened this issue Oct 2, 2016 · 5 comments
Closed

Request: MailboxAddress constructor for email part only #267

nvivo opened this issue Oct 2, 2016 · 5 comments
Labels
enhancement New feature or request

Comments

@nvivo
Copy link

nvivo commented Oct 2, 2016

This sounds like a silly request and there may be a reason why this wasn't implemented this way, so sorry in advance.

In most applications when I send an email I have only the address part. This looks like a very common case and the RFC seems to accept the addr-spec as a mailbox, but MailboxAddress requires both name and address.

Either InternetAddress.Parse("foo@bar.com") and new MailboxAddress(String.Empty, "foo@bar.com) return a similar MailboxAddress object, so any reason to not simply support new MailboxAddress("foo@bar.com")?

Thanks.

@jstedfast
Copy link
Owner

Very few people seem to care about creating MailboxAddresses w/o a name, so I didn't bother to add .ctors for that.

That said, sure, I can add them...

@jstedfast jstedfast added the enhancement New feature or request label Oct 2, 2016
@nvivo
Copy link
Author

nvivo commented Oct 3, 2016

You're fast! Thanks!

@jstedfast
Copy link
Owner

So the problem is that it turns out a lot of people thought that a MailboxAddress .ctor that takes only a single string argument is meant to parse out the name and address from that single string.

I think I'm going to [Obsolete] this .ctor and tell people to use MailboxAddress.Parse() instead to eliminate confusion and bad habits.

@nvivo
Copy link
Author

nvivo commented Apr 23, 2017

Wouldn't adding a comment on the method be better? It's your call, but since the RFC allows the email only, the implementation is correct. Removing that and forcing the null argument instead of just letting people fix their code sound wrong.

I'd propose simply adding the comment on the method and people should see when choosing the overload.

@jstedfast
Copy link
Owner

You can still pass null or string.Empty as the 'name' argument to the existing .ctor

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants