JS macht die Typprüfung nicht implizit aber vielleicht braucht man sie irgendwann explizit. Oder der Aufruf erfolgt aus ner typisierten Sprache wie Java?
Die "Praxis" null als gewolltes "undefined" zu nutzen hat sich vielleicht eingebürgert, dahingehend designt und vorgesehen wurde es aber nicht.
Wie gesagt, ich bezweifle nicht, dass hier offensichtlich Java als streng typisierte Sprache Pate gestanden hat und die Core-API dieser nachempfunden wurde. In diesen Sprachen macht null als Gegensatz zu undefined Sinn. Gleichzeitig verletzt ECMAScript die Regel, dass eine Methode immer einen bestimmten Typ zurückgibt, mit undefined ständig. Das DOM ist da konsequent, z.B. getAttribute gibt einen leeren String zurück, wenn kein solches Attribut existiert, weil der Rückgabewert eben immer ein String ist. Das halte ich für Quatsch in Sprachen wie ECMAScript und würde keine JS-API so entwerfen. Aber gut, das DOM ist eben programmiersprachenunabhängig und nutzt daher den kleinsten gemeinsamen Nenner.
ECMAScript ist eine funktionale, dynamisch getypte Sprache, die auf komplett auf mutable objects, Prototypen und funktionalem Scope basiert. Trotzdem hat sie unzählige Einsprengsel, die aus streng getypten, konventionell klassenbasierten Sprachen stammen. Ich weiß nicht, wie Perl da tickt, aber in Python und Ruby, die hinsichtlich Typen mit ECMAScript wohl eher zu vergleichen sind als Java, gibt es m.W. keine Unterscheidung zwischen null und undefined. In Python gibt es None, in Ruby nil. In ECMAScript halte ich die Aufspaltung in undefined und null für ziemlich willkürlich und eben nur historisch erklärbar. - Genauso wie z.B. der new-Operator, der eine Analogie zu klassenbasierten Sprachen ist und im funktionalen/prototypischen JavaScript überhaupt nicht gebraucht wird bzw. von dem Leute wie Crockford abraten, weil er die Natur der Sprache mehr verhüllt als offenlegt.
Die Frage mit den optionalen Parametern stellt sich in einer Sprache wie ECMAScript m.E. nicht. Ich finde es schwierig, da aussagekräftige Beispiele zu finden. Es ist gang und gäbe, dass Methoden überladen werden, sodass optionale Parameter einfach weggelassen werden und die Parameteranzahl variabel ist. JavaScript-APIs werden so implementiert, dass gemäß dem Paradigma der schwachen Typisierung aus dem Wert immer etwas (hoffentlich) sinnvolles gemacht wird bzw. er ansonsten einfach verworfen wird. Wenn ein truthy-Wert benötigt wird, dann ist es egal, ob "", 0, false, undefined oder null hereinkommt. Wenn z.B. ein String erwartet wird, dann werden auch alle anderen Typen akzeptiert und entsprechend gecastet.
Mathias