upvote

points

by kleiba8 hours ago |
comments
upvoteby munk-a8 hours ago|
next
[-]
Without any other context? Nothing - it's just a type alias...

But the context this type of an alias should exist in is one where a string isn't turned into a PhoneNumber until you've validated it. All the functions taking a string that might end up being a PhoneNumber need to be highly defensive - but all the functions taking a PhoneNumber can lean on the assumptions that go into that type.

It's nice to have tight control over the string -> PhoneNumber parsing that guarantees all those assumptions are checked. Ideally that'd be done through domain based type restrictions, but it might just be code - either way, if you're diligent, you can stop being defensive in downstream functions.

reply
upvoteby seanwilson8 hours ago|
parent|
next
[-]
> All the functions taking a string that might end up being a PhoneNumber need to be highly defensive

Yeah, I can't relate at all with not using a type for this after having to write gross defensive code a couple of times e.g. if it's not a phone number you've got to return undefined or throw an exception? The typed approach is shorter, cleaner, self-documenting, reduces bugs and makes refactoring easier.

reply
upvoteby thfuran8 hours ago|
parent|
prev|
next
[-]
>But the context this type of an alias should exist in is one where a string isn't turned into a PhoneNumber until you've validated it.

Even if you don't do any validation as part of the construction (and yeah, having a separate type for validated vs unvalidated is extremely helpful), universally using type aliases like that pretty much entirely prevents the class of bugs from accidentally passing a string/int typed value into a variable of the wrong stringy/inty type, e.g. mixing up different categories of id or name or whatever.

reply
upvoteby barmic127 hours ago|
parent|
prev|
[-]
one issue is it’s not a type alias but a type encapsulation. This have a cost at runtime, it’s not like in some functionnals languages a non cost abstraction.
reply
upvoteby vips7L6 hours ago|
parent|
[-]
Correctness is more important than runtime costs.
reply
upvoteby esafak7 hours ago|
prev|
next
[-]
Validation, readability, and prevention of accidentally passing in the wrong string (e.g., by misordering two strings arguments in a function).
reply
upvoteby jalk8 hours ago|
prev|
next
[-]
An explicit type
reply
upvoteby dylan6048 hours ago|
parent|
[-]
Obviously the pseudo code leaves to the imagination, but what benefits does this give you? Are you checking that it is 10-digits? Are you allowing for + symbols for the international codes?
reply
upvoteby xboxnolifes3 hours ago|
parent|
next
[-]
You have functions

    void callNumber(string phoneNumber);
    void associatePhoneNumber(string phoneNumber, Person person);
    Person lookupPerson(string phoneNumber);
    Provider getProvider(string phoneNumber);
I pass in "555;324+289G". Are you putting validation logic into all of those functions? You could have a validation function you write once and call in all of those functions, but why? Why not just parse the phone number into an already validated type and pass that around?

    PhoneNumber PhoneNumber(string phoneNumber);
    void callNumber(PhoneNumber phoneNumber);
    void associatePhoneNumber(PhoneNumber phoneNumber, Person person);
    Person lookupPerson(PhoneNumber phoneNumber);
    Provider getProvider(PhoneNumber phoneNumber);
Put all of the validation logic into the type conversion function. Now you only need to validate once from string to PhoneNumber, and you can safely assume it's valid everywhere else.
reply
upvoteby flqn8 hours ago|
parent|
prev|
next
[-]
Can't pass a PhoneNumber to a function expecting an EmailAddress, for one, or mix up the order of arguments in a function that may otherwise just take two or more strings
reply
upvoteby munk-a8 hours ago|
parent|
prev|
next
[-]
That's going to be up to the business building the logic. Ideally those assumptions are clearly encoded in an easily readable manner but at the very least they should be captured somewhere code adjacent (even if it's just a comment and the block of logic to enforce those restraints).
reply
upvoteby bjghknggkk8 hours ago|
parent|
[-]
How to make a crap system that users will hate: Let some architecture astronaut decide what characters should be valid or not.
reply
upvoteby JambalayaJimbo8 hours ago|
parent|
prev|
next
[-]
If you are not checking that the phone number is 10 digits (or whatever the rules are for the phone number for your use case), it is absolutely pointless. But why would you not?
reply
upvoteby jghn8 hours ago|
parent|
[-]
I would argue it's the other way around. If I take a string I believe to be a phone number and wrap it in a `PhoneNumber` type, and then later I try to pass it in as the wrong argument to a function like say I get order of name & phone number reversed, it'll complain. Whereas if both name & phone number are strings, it won't complain.

That's what I see as the primary value to this sort of typing. Enforcing the invariants is a separate matter.

reply
upvoteby bjghknggkk8 hours ago|
parent|
prev|
[-]
And parentheses. And spaces (that may, or may not, be trimmed). And all kind of unicode equivalent characters, that might have to be canonicalized. Why not treat it as a byte buffer anyway.
reply
upvoteby waynesonfire8 hours ago|
prev|
[-]
What did you lose?
reply