Type Polymorphic Functions in TypeScript | Hacker News Reader

Type Polymorphic Functions in TypeScript

zhenghao.io

37 pointsCapnCrunchie14 comments

Open articleView on HN

Can function overloads be marked private or deprecated independently?

Does the implementation need to repeat the effective union type?

> 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`;

I would recommend leveraging the RSS feed

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

great content on TypeScript as usual!

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

A developer talking about preferring unit tests is never lazy !

What amount of work?

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.

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.

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

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.

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()

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.

Reply on news.ycombinator.com