Comments on: Javascript function overloading https://kinsey.no/blog/index.php/2007/11/15/javascript-function-overloading/ Because I want to be like the cool kids too Thu, 08 Apr 2010 20:28:58 +0000 hourly 1 https://wordpress.org/?v=5.8.18 By: oyvind.kinsey https://kinsey.no/blog/index.php/2007/11/15/javascript-function-overloading/comment-page-1/#comment-4 Thu, 15 Nov 2007 17:55:42 +0000 http://kinsey.no/wp/?p=11#comment-4 @Bertrand
I’m not quite sure what you mean by having to specify the signature at two different places, as this is only done when adding the overload.
As of typeof’s limitation this was only some code I made to show that it was indeed possible to quite easily make typespecific overloads.

To extend it to custom object types one could use a method similar to that used in ASP.NET AJAX to check the type of arguments.
Off course, this would create additional overhead and more code to execute, but hey, thats what you get if you absolutely need typespesific overloading.

I would not use this code myself in production as its easier to just have different method names.
So about overloading in general I’m with you, I don’t need it.

]]> By: oyvind.kinsey https://kinsey.no/blog/index.php/2007/11/15/javascript-function-overloading/comment-page-1/#comment-504 Thu, 15 Nov 2007 17:55:00 +0000 http://kinsey.no/wp/?p=11#comment-504 @Bertrand
I’m not quite sure what you mean by having to specify the signature at two different places, as this is only done when adding the overload.
As of typeof’s limitation this was only some code I made to show that it was indeed possible to quite easily make typespecific overloads.

To extend it to custom object types one could use a method similar to that used in ASP.NET AJAX to check the type of arguments.
Off course, this would create additional overhead and more code to execute, but hey, thats what you get if you absolutely need typespesific overloading.

I would not use this code myself in production as its easier to just have different method names.
So about overloading in general I’m with you, I don’t need it.

]]> By: Bertrand Le Roy https://kinsey.no/blog/index.php/2007/11/15/javascript-function-overloading/comment-page-1/#comment-3 Thu, 15 Nov 2007 17:41:39 +0000 http://kinsey.no/wp/?p=11#comment-3 I think this suffers from the same problems as John Resig’s suggestion and some more. It’s inconvenient to have to specify the signature at two different places: there’s considerable risk for typos (especially as the code is not very resilient to stuff like spaces) and the two versions of the signatures are at different places, making management more difficult. Relying on typeof to determine the type limits you to the handful of types it supports and does nothing for the richer type systems that JS allows and that are now widely used. And of course, the performance overhead is still there as there is heavy use of the arguments pseudo-array (which has horrendous performance), an additional level of indirection, and quite a lot of code to execute on every single function call. And of course tooling and reflection scenarios are just killed by all that.

Again, the real question is do we really think we need overloading that badly? My personal take is that we don’t.

]]> By: Bertrand Le Roy https://kinsey.no/blog/index.php/2007/11/15/javascript-function-overloading/comment-page-1/#comment-503 Thu, 15 Nov 2007 17:41:00 +0000 http://kinsey.no/wp/?p=11#comment-503 I think this suffers from the same problems as John Resig’s suggestion and some more. It’s inconvenient to have to specify the signature at two different places: there’s considerable risk for typos (especially as the code is not very resilient to stuff like spaces) and the two versions of the signatures are at different places, making management more difficult. Relying on typeof to determine the type limits you to the handful of types it supports and does nothing for the richer type systems that JS allows and that are now widely used. And of course, the performance overhead is still there as there is heavy use of the arguments pseudo-array (which has horrendous performance), an additional level of indirection, and quite a lot of code to execute on every single function call. And of course tooling and reflection scenarios are just killed by all that.

Again, the real question is do we really think we need overloading that badly? My personal take is that we don’t.

]]>