5 ms·

Hey author here. I don't think I'm ill informed. Most users understand that when they enter FoObAr@gmail.com somewhere that they might see foobar@gmail.com as

Hey author here. I don't think I'm ill informed. Most users understand that when they enter FoObAr@gmail.com somewhere that they might see foobar@gmail.com as their account somewhere. Literally every service I use does that. For years I used to enter my email address as FirstnameLastname@gmail.com and all those systems (Google products, and more) show me firstnamelastname@gmail.com. Heck, even my email provider shows my email as lowercase when I receive an email. The other thing about the alias it's clear you didn't read what I wrote. I didnt' say that a user's email address should get modified in the system and the +bar should get cut out. I was saying that it would be a handy feature to have a type which understands these things so you can run a search against your dataset if you want to match up people. In some systems that might make sense, in others not. Nobody forces you to apply the business rules of someone else. Besides you seem to fundamentally misunderstand something here. > And there's now a problem with parsing the address, and you need to surface the exact problem: but how can a user see it from all the normalisation you just "helpfully" did? How a system thinks of an object internally and how it is displayed to the user are two different things. In fact, every well designed software does what I suggested in a variety of places. When I register somewhere with foobar@gmamil.com but then a year later use the password reset function and enter Foobar@gmail.com then I will receive a password reset link as anyone would expect. Find me one popular software that doesn't do that. Anything else would be an awful user experience. Anyhow, the point is that YOU design your types the way they help to accomplish YOUR goals. I just gave some silly examples to demonstrate how one can use types to do useful things. > this is a begginers fascination with OOP Actually what I described in my blog post is bread and butter in FP and personally I consider myself more of an FP developer as I've been doing mostly F# for many years now but don't let the facts distract you from being unnecessarily rude and offensive for no apparent reason.

necovek 4y ago
Thank you for responding. I never said either that you are "normalizing away" the +bar thing, but that you are building in a non-standard convention to parse semantics of an email address which (mostly) hold true for one particular provider (gmail.com), without at all acknowledging that this is gmail-specific. Even if you are aware of it, your readers might not be. In short, I do agree that your examples are silly, but I disagree that you demonstrate how they can do useful things: you mostly show how you can do silly things with them instead. Note that you are suggesting this as a pattern: even if your users are accustomed to their email addresses being normalized, they might not be accustomed to other things being so. If one takes your advice, you'd have a FullName, FirstName, LastName types as well which does the normalization based on the language, and using eg. Unicode NF. I do agree that you should do the things that have value, but I don't see you showing that value anywhere (as your example has a bunch of problems I highlighted, yet the benefits are?). Note that I've been there as well early on in my career: it feels so satisfying to imagine a world where our data types smartly represent exactly the object they need to, with all the properties and actions one can do with it. However, it quickly breaks up in the real world, and you end up with IncomingEmailAddress, SMTPEnvelopeEmailAddress, UserProvidedEmailAddress etc instead. This is not to say that if you've got a specific application that does some smart handling of an email address (like having aliasing rules for different popular providers) — eg. a mailing list app — but if that's not your business domain, a string is usually a better choice for what is essentially a string. Let me give you another simple yet convoluted example that usually quickly breaks: compund types (even your EmailAddress would be used in different contexts). For simplicity, let's go to my example of Name: (FirstName, LastName). For display purposes, you might want to show Name as "<FirstName> <LastName>" on a profile page (except for East Asian names), but collate according to LastName. Now your Name needs to understand the context it's in, and what you hoped would be a trivial semantic structure is anything but. All of this is to say: keep your data structures as simple as possible for as long as you can. Your future self will thank you.

necovek 4y ago

Thank you for responding. I never said either that you are "normalizing away" the +bar thing, but that you are building in a non-standard convention to parse semantics of an email address which (mostly) hold true for one particular provider (gmail.com), without at all acknowledging that this is gmail-specific. Even if you are aware of it, your readers might not be. In short, I do agree that your examples are silly, but I disagree that you demonstrate how they can do useful things: you mostly show how you can do silly things with them instead. Note that you are suggesting this as a pattern: even if your users are accustomed to their email addresses being normalized, they might not be accustomed to other things being so. If one takes your advice, you'd have a FullName, FirstName, LastName types as well which does the normalization based on the language, and using eg. Unicode NF. I do agree that you should do the things that have value, but I don't see you showing that value anywhere (as your example has a bunch of problems I highlighted, yet the benefits are?). Note that I've been there as well early on in my career: it feels so satisfying to imagine a world where our data types smartly represent exactly the object they need to, with all the properties and actions one can do with it. However, it quickly breaks up in the real world, and you end up with IncomingEmailAddress, SMTPEnvelopeEmailAddress, UserProvidedEmailAddress etc instead. This is not to say that if you've got a specific application that does some smart handling of an email address (like having aliasing rules for different popular providers) — eg. a mailing list app — but if that's not your business domain, a string is usually a better choice for what is essentially a string. Let me give you another simple yet convoluted example that usually quickly breaks: compund types (even your EmailAddress would be used in different contexts). For simplicity, let's go to my example of Name: (FirstName, LastName). For display purposes, you might want to show Name as "<FirstName> <LastName>" on a profile page (except for East Asian names), but collate according to LastName. Now your Name needs to understand the context it's in, and what you hoped would be a trivial semantic structure is anything but. All of this is to say: keep your data structures as simple as possible for as long as you can. Your future self will thank you.