[galaxyLogic]

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.

[exdsq]

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

[pc86]

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.

[galaxyLogic]

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

[anoctopus]

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.