Let’s say we use `inline class EmailAddress(val va...

# random

[Marc Knaup]

Let’s say we use inline class EmailAddress(val value: String) for "<mailto:[e-mail]|[e-mail]>"
What is or should the combination of name + email address be called?

data class EmailRecipient(val address: EmailAddress, val name: String? = null)?
EmailContact? MailboxAddress? EmailUser? NamedEmailAddress?
Got any idea or is there even any RFC definition for that?

[Matteo Mirk]

Try to draw inspiration from email clients and what vocabulary they use. I think “Contact” is a good name, it’s generic enough and could be extended in the future to contain other info.
“EmailRecipient” is too narrow, it only deals with one half of the domain: an email can be both a sender and recipient.
“MailboxAddress” is not correct because an internet mailbox is identified only by the email address.
“EmailUser” doesn’t make too much sense in my opinion, and could be subject to ambiguity.
“NamedEmailAddress” is also nice as it highlights the composed nature of the object.

If you want to look for some inspiration try reading the Email RFC: https://tools.ietf.org/html/rfc2822

[Marc Knaup]

Thank you for your thoughts!
It’s true that it can also be a sender. In many documentations it’s still named Recipient though. But I agree that that’s confusing 🙂

In the RFC you’ve linked it’s actually called “mailbox” 😉

Normally, a mailbox is comprised of two parts: (1) an optional display name that indicates the name of the recipient (which could be a person or a system) that could be displayed to the user of a mail application, and (2) an addr-spec address enclosed in angle brackets (“<” and “>”). There is also an alternate simple form of a mailbox where the addr-spec address appears alone, without the recipient’s name or the angle brackets.

I’m trying to avoid something as generic as Contact.
Email functionality is usually just a tiny piece of a larger project and short names like that have a high chance of collision.
I had that problem just now where Contact from an email library collides with Contact from the CRM I’m writing.
Also, the idea is to not extend the the class with other properties in the future but have it only for that one purpose :)

[Matteo Mirk]

You’re welcome, sorry for my imprecision, I remembered wrong. In the end try to come up with a name that suits your domain, that makes sense when referred in a sentence about that subsystem. This is the only good advice I feel to give.

[Matteo Mirk]

Minor issue: if exact same names collide, shouldn’t be a problem anyway, that’s what package or namespaces were invented for 😉

[Marc Knaup]

I’m typically thinking in terms of abstraction & standardization.
E.g., what would EmailRecipient or alike look like in a standard library or an email library? 🙂

[Marc Knaup]

Packages are a technical solution but not really developer-friendly.
I’d still have two Contact in autocompletion that I’d keep mixing up. And I’d need an implicit import in addition to a star-import.

[thanksforallthefish]

I would avoid super generic terms like Contact, not as much because of repetition (when we look at words, the same word can have different meaning and/or be used in different context) but mostly because you might fail to convey meaning. given your name is optional and the rfc, MailboxAddress looks the best choice to me, provided when you talk with colleagues/business you also use the same wording