Type Polymorphic Functions in TypeScript (opens in new tab)

I'm not sure if it is a good idea for a function to do different things based on the type of its argument. When I read code and see function call I would like to know what it does. Now if it can do different things based on the type of argument I pass to it, I can't easily tell what it does, especially when the argument I pass to it may be my argument, or may be the result of some other function I call.

A more readable solution I think is to define multiple functions whose names differ by a suffix that indicates argument type.

Arguments with default values are not really "polymorphic". They juts make it possible to call the function with fewer arguments.

And instead of "polymorphic functions" why not use ES6 classes which are polymorphic by their nature. The class of the recipient determines which method gets executed. There too you can use the approach of defining multiple similar methods whose name differs by a suffix indicating their argument-type.

exdsq4y ago

Here are some reasons why you might want this https://en.m.wikipedia.org/wiki/Ad_hoc_polymorphism

pc864y ago

There are probably better ways to achieve this than some pseudo-Hungarian notation on method signatures, right?

I'm predisposed to agree with you but I would hate looking at code and seeing method signatures like DoThingString(string), DoThingInt(int), etc.

galaxyLogic4y ago

Those look clumsy but you would only use something like that when in fact you define a similar but not the same operation for Strings and Integers. And then the argument-type-suffix would look more natural. For instance:

   saveInt (i)

   saveString(s)

   saveBox(box)

   saveCat (cat)

And then it might make more sense to define classes Box and Cat and say:

   box.save()

   cat.save()

anoctopus4y ago

Parametric polymorphism is great and undervalued by most languages, but ad hoc polymorphism is also valuable at times, mainly when the polymorphic function represents the same abstract operation on distinct types.

j / k navigate · click thread line to collapse

14 comments

seniorsassycat4y ago

Can function overloads be marked private or deprecated independently?

Does the implementation need to repeat the effective union type?

TheCoelacanth4y ago

> Can function overloads be marked private or deprecated independently?

Private independently, no. Deprecated independently, yes.

> Does the implementation need to repeat the effective union type?

Yes, or use something even broader like `any`;

sedivy944y ago

I would recommend leveraging the RSS feed

lloydatkinson4y ago

I always really enjoy his articles, I wish he had a newsletter so I could know when a new one is out.

iron4wine4y ago

great content on TypeScript as usual!

gwill4y ago

given that amount of work(and maybe i'm just being lazy), wouldn't you prefer a unit test?

exdsq4y ago

A developer talking about preferring unit tests is never lazy !

folkrav4y ago

If I can express something using the type system I'll always go with that first, so I don't even need the test to enforce the same contract.

frosted-flakes4y ago

What amount of work?

galaxyLogic4y ago

A more readable solution I think is to define multiple functions whose names differ by a suffix that indicates argument type.

Arguments with default values are not really "polymorphic". They juts make it possible to call the function with fewer arguments.

exdsq4y ago

Here are some reasons why you might want this https://en.m.wikipedia.org/wiki/Ad_hoc_polymorphism

pc864y ago

There are probably better ways to achieve this than some pseudo-Hungarian notation on method signatures, right?

I'm predisposed to agree with you but I would hate looking at code and seeing method signatures like DoThingString(string), DoThingInt(int), etc.

galaxyLogic4y ago

   saveInt (i)

   saveString(s)

   saveBox(box)

   saveCat (cat)

And then it might make more sense to define classes Box and Cat and say:

   box.save()

   cat.save()

anoctopus4y ago

j / k navigate · click thread line to collapse