if(minVariabel instanceof minKlasse) { ... }minVariabel er en instans av klassen minKlasse. For å lage et objekt (en instans) av en klasse brukes new-operatoren, eksempelvis minVariabel = new minKlasse();
Poenget med instanceof-operatoren er at den gir deg mulighet til å teste hvilken klasse et objekt er hentet fra, og således kun benytte metoder og egenskaper du vet eksisterer for objekter av den klassen. Du kan med andre ord lage en metode som gjør forskjellige ting avhengig av klassen den tilhører, noe som igjen kan gi mer kompakt og oversiktlig kode.
Ideen er god, men så viser det seg at teori og praksis ikke stemmer. I det tidligere blogginnlegget er det nevnt at MSIE(Microsoft Internet Explorer) ikke kan teste objekter sendt som argumenter fra et annet vindu. Spørsmålet var nå om det eksisterte andre varianter der testene også feilet, og hvilke browsere som sluttet å fungere.
Til å hjelpe meg med dette har jeg laget tre varianter av samme test og lagt det ut som et eget testcase. Dokumentene der er holdt på engelsk eftersom jeg vil kunne bruke det i bugrapporter. Første variant (#1) av testen kaller en funksjon i et (annet) vindu med lokale variabler som argument. Det er samme problemområde som nevnt i det tidligere blogginnlegget, og hvor MSIE(Microsoft Internet Explorer) feiler. Funksjonen kalles to ganger, først med en primitiv tall-verdi, det vil si en vanlig tall-variabel laget med var notNumberClass = 8;. Andre gang kalles den med et objekt skapt fra klassen Number() med var isNumberClass = new Number(8);. Resultatet av det første kallet skal være at variabelen (objektet) ikke er instans av noen klasse, mens det andre kallet skal definere objektet som en instans av klassene Number og Object (alle objekter i JavaScript nedstammer fra Object).
Andre variant (#2) snur om på problemstillingen ved at den kaller en lokal funksjon, det vil si i ett og samme vindu, mens argumentet flyttes rundt. Igjen gjøre testen med både en primitiv verdi og en instans av Number-klassen og skal i utgangspunktet gi samme resultater som for #1. Jeg var usikker på om problemet ville være likt for de som ikke takler #1, men ut fra resultatet ser de ut til å betrakte det som samme problem.
Siste variant (#3) kaller en funksjon hvor variablene befinner seg i samme vindu som funksjonen, det vil si at både funksjon og argument flyttes rundt. Den variabelen som testes er dermed lokal til vinduet funksjonen befinner seg i. Her er det ingen problemer overhodet og alle browsere gir riktige resultater.
Jeg har sjekket testcaset med fire browsere:
* Microsoft Internet Explorer 6
* Mozilla 1.5
* Opera 7.23
* Konqueror 3.1-15 Red Hat
Av disse er det bare Mozilla 1.5 som gjør tingene riktig i alle 3 testene. De tre andre får riktige svar i test #3, men nekter for at objektet er en instans av klassene Number og Object i test #1 og #2. Foreløpig har jeg ikke lest nok av ECMA-262 til å forstå hvorfor de oppfører seg om de gjør, men ut fra definisjonen av instanceof finner jeg det noe overraskende at den ikke skal fungere på tvers av vinduer/rammer.]]>
La oss se på et eksempel på bruk av disse tre objektmodellene. Gitt at vi har følgende element i et HTML-dokument:
<form name="mittSkjema" id="mittSkjema"> ... </form>Vi har så en variabel 'mittSkjema' og vi ønsker at denne skal være en referanse til skjemaet. Kjernen av språket tilbyr ikke noe om skjemaer, men objektmodellene gjør det. For å opprette referansen kan vi for eksempel gjøre:
var mittSkjema; // variabel for skjemaet
if(document.all) {
// I Internet Explorers proprietære objektmodell har vi metoden document.all()
// for å hente ut enkelt-elementer av dokumentet.
mittSkjema = document.all('mittSkjema');
} else if(document.getElementById) {
// I W3Cs Document Object Model level 1 tilbys getElementById()
mittSkjema = document.getElementById('mittSkjema');
} else if(document.forms) {
// Netscape Navigator 4.x (og DOM level 0) benytter arrayet document.forms[]
// og krever at skjemaet er navngitt gjennom name-attributtet
mittSkjema = document.forms['mittSkjema']
}Mens objektmodellen er veldig omfattende er kjernen av språket ikke voldsomt stor. Tar vi en titt på Netscapes dokumentasjon for kjernen av JavaScript v1.5 ser vi at den består av noen få objekter, globale egenskaper, funksjoner, statements, kommentarer samt de forskjellige operatorene. Det er ikke voldsomt stort og derfor rimelig lett å lære.
Når vi lager Date()-objekter arbeider vi med kjernen av språket. Et eksempel er bruken av disse objektene for å finne ut hvor lang tid det tok å gjøre noe:
var start = new Date();
// ...
// Her ligger koden vi vil vite tidsforbruket for
// ...
var end = new Date();
// Tidsforbruket regnet ut i millisekunder
var timeUsed = end.getTime() - start.getTime();Dette skillet mellom kjerne og objektmodell er viktig når vi søker svar på spørsmål. Kjernen er dokumentert for seg selv og problemer med den delen av språket må således sjekkes opp mot den dokumentasjonen. Likeledes er vi nødt til å sjekke dokumentasjon for objektmodellen når problemet ligger der. Unntaket fra denne regelen er Netscapes dokumentasjon for JavaScript frem til og med v1.3, hvor de ikke har noe skille overhodet og koker suppe på alt sammen. Det kan være lett forvirrende.
]]>var foo = new Number(8);
alert(foo instanceof Number);var foo = 8; alert(foo instanceof Number); gir 'false' som svar)
Problemet er altså at en objektreferanse til et Number-objekt sendt som et argument til en funksjon i et annet vindu (rammer er jo også vindusobjekter) ikke lenger er et skikkelig Number-objekt. Efter mye frem og tilbake samt en tur med gravemaskin i Microsofts JScript-dokumentasjon bestemte vi oss for at det beste var kanskje å finne en egenskap som identifiserte tallet. Ikke overraskende mener IE at konstruktøren til 'foo' er et tall, slik at følgende lille kodesnutt funker i IE:
if(n.constructor.toString().indexOf("Number") != -1) { }setInterval().
Biblioteket ligger ute på filen timer-lib.zip. Det er rimelig godt dokumentert i kildekoden og burde således være relativt lett å ta i bruk. Jeg har hatt det liggende tilgjengelig på web ganske lenge efter at det var interesse for det på DynApi2s mailing-liste "dynapi-help". Mottakelsen der var delt da animasjonene viste seg å gå dobbelt så fort som normalt, men det var jo liksom meningen. :)
Er løsningen vakker? Ikke godt å si, men jeg syns nå den i det minste kan kalles "elegant". Selv-korrigerende og flertrådet og allikevel rimelig enkel i bruk. Det er slikt jeg finner glede i å skrive.]]>
nice find . -type f -name "*.html" -exec ~/perl/getscripts.pl {} \;