Das Problem bei so einer Vorgehensweise im Vergleich zu Duck Typing ist, dass nicht beteiligte und nicht benutzte Eigenschaften abgefragt werden.
Habe "duck typing" gegooglet (Wikipedia und Artikel bzgl. typeof etc.) und bin mir immer
noch nicht sicher, was genau damit gemeint ist. In Bezug auf Arrays vielleicht Folgendes(?):
Wenn es die Eigenschaften erfüllt, die ich von einem Array und nur von einem Array
erwarte, dann verwende ich es als Array bzw. nenne es "Array". Wenn also ein Etwas
eine length besitzt, man auf es mit der Bracket-Methode zugreifen kann etc., dann ist's ein Array für mich.
Also eine Art pragmatische Deskriptions-Definition?
arguments.callee beispielsweise ist deprecated und der Zugriff darauf im ECMAScript 5 Strict Mode wirft eine Exception.
Oh, gut zu wissen, das war mir bisher entgangen. Wäre callee aber nicht depricated,
so erfüllte doch mein Check auf das Vorhandensein dieser property die Idee von
duck typing, oder? Es wird genau die Eigenschaft abgefragt, die ich von arguments
und nur von arguments erwarte. >>Verhält sich wie arguments => ist arguments<<
Ich würde jedem raten, schon jetzt nur noch im Strict Mode zu entwickeln, daher würde ich keine Bibliothek auf einem deprecated Feature aufbauen. Wenn du nirgendwo wirklich die Unterscheidung zwischen »listenartig« und Array, Arguments und NodeList/HTMLCollection brauchst, so würde ich gar nicht erst versuchen, sie zu unterscheiden.
»»
Da hast Du wohl voll und ganz Recht. Werde callee rauspfeffern und mein Script auch
dahingehend umschreiben, dass ich keine "Ist-so-ähnlich-wie'n-Array-Eigenschaft" definiere.
Wenn ich dich richtig verstanden habe, braucht deine Funktion hauptsächlich die Unterscheidung zwischen Boolean, String, »listenartig« und Listen mit Elementen. Das ist müsste robust umsetzbar sein.
Wird in Angriff genommen :}
Vielen Dank Dir,
Laura