Med al respekt, barklund - men det er noget værre rod :) Du kan ikke have tal som property-navne i et objekt. I så fald skulle du kunne skrive:
var val = 5 var hash = new Object(); hash.5 = true; hash.7 = true; hash.9 = true; if (hash[val]) { document.write("hello world") }
- og det går som bekendt ikke. Derfor bør du i stedet skrive:
var val = 5 var hash = new Array(); hash[5] = true; hash[7] = true; hash[9] = true; if (hash[val]) { document.write("hello world") }
Desværre er JavaScript noget rod på dette punkt, idet et objekt og et arrey faktisk er to repræsentationer af samme underliggende datastruktur. Læs evt: http://www.eksperten.dk/artikler/227
Derfor bør vi som kodere selv holde lidt styr på meningen og gennemskueligheden af koden ;o)
Olebole, jeg valgte bevidst ikke et array, for arrays bør ikke bruges til hashtables. Og efter min bedste overbevisning må man gerne have tal som egenskabsnavne i objektet på den måde. Array's bør bruges til fortløbende liste af elementer.
Hvis man bruger arrayøs til hashtables, så fylder man alt muligt op ved at instantiere et ganske komplekst objekt med en masse metoder, man overhovedet ikke har behov for.
Og argumentet med, at .operatoren ikke kan bruges synes jeg ikke holder. Bare fordi jeg kan skrive:
var foo = "flaf"; bar[foo] = "noget";
Så kan jeg jo ikke skrive (med samme resultat):
bar.foo = "noget";
Og jeg kan skrive:
bar["foo-flaf"] = "noget";
Men ikke:
bar.foo-flaf = "noget";
Array access operatoren, '[]', kan mere end egenskabsoperatoren, '.'. De kan ikke det samme, så jeg synes ikke, det er et gyldigt argument.
Men jeg skal da gerne konsolidere med ECMAScript specifikationen. Jeg har dog netop argumenteret som ovenstående for, at man bør bruge objekter og ikke arrays til hashtables i min bog om ActionScript.
barklund >> Det er her, vi støder mod nogle af JS's ulemper, der udspringer i dets loose (læs: sloppy) arkitektur (en egenskab, det deler med andre sript-sprog - f.eks. PHP).
Du har helt. Identifiers skal i JS altid begynde med et bogstav eller en underscore. En åbenbart væsentlig afvigelse herfra er objekter, hvor et element kan indentificeres ved et navn, et tal-index eller en streng: {bla:"noget", 56:"noget andet", "tja":"noget tredie"}
- hvor 'bla' ikke er en variabel ... blot et name, der ikke er escaped af gåseøjne.
Det faktum, at object og array blot er to forskellige interfaces, der repræsenterer samme datastruktur, gør, at tingene flyder på en temmelig uhensigtsmæssig måde. Netscape selv roder såmænd også rundt i begreberne i deres JS1.4-reference:
------------------------- snip ------------------------- Indexing Object Properties ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯ In JavaScript 1.0, you can refer to an object’s properties by their property name or by their ordinal index. In JavaScript 1.1 or later, however, if you initially define a property by its name, you must always refer to it by its name, and if you initially define a property by an index, you must always refer to it by its index.
This applies when you create an object and its properties with a constructor function, as in the above example of the Car object type, and when you define individual properties explicitly (for example, myCar.color = "red"). So if you define object properties initially with an index, such as myCar[5] = "25 mpg", you can subsequently refer to the property as myCar[5].
The exception to this rule is objects reflected from HTML, such as the forms array. You can always refer to objects in these arrays by either their ordinal number (based on where they appear in the document) or their name (if defined). For example, if the second <FORM> tag in a document has a NAME attribute of “myForm”, you can refer to the form as document.forms[1] or document.forms["myForm"] or document.myForm. ------------------------- /snip -------------------------
- hvor man diskuterer indeksering af properties på *objekter* ... blot for i tredie afsnit at nævne visse *arrays* som afvigelser fra den omtalte regel(?) :)
Hvad angår performance og forskellen på at instantiere henholdsvis objekter og arrays, så er den fra ikke eksisterende til ganske lille - afhængig af browser. Mindst i IE/Opera størst i FF (hvor objektet er ca. 10-15% hurtigere end arrayet). Forskellen i RAM-forbrug er endnu mindre. Det er jo altsammen helt som forventet og stemmer fint overens med de teoretiske fordele ved prototyping, at de ekstra metoder på Array-objektet ikke betyder noget særligt i praksis.
Som en sjov lille ting kan det i øvrigt nævnes, at IE ganske forventet er ca. 10 gange langsommere end FF :)
Anyway, skal man virkelig opnå performanceforbedring, bør man skrive: var hash = {5:true, 7:true, 9:true};
- i stedet for: var hash = new Object(); hash[5] = true; hash[7] = true; hash[9] = true;
Den første kører dobbelt så hurtigt i FF - og 3-4 gange hurtigere i IE.
I betragtning af den yderst ringe forskel på performance ved brugen af de array og object, foretrækker jeg stadig at holde mig til logikken og kun anvende objekter med property-navne i form af strenge - og arrays til streng- og tal-indeksering.
Et væsentligt kendetegn ved JS er objekt-dot-notationen, som er arvet fra C-sprogene. Den finder jeg det personlig fjollet at sætte over styr i nogle enkelte special-instanser af objekter ... men det er jo et spørgsmål om kodestil og -kultur. Det er min opfattelse, min kode bliver mere logisk og stringent på den måde - og at det er noget rod, at man kun kan hente properties med array-notation på visse objekter :)
Synes godt om
Ny brugerNybegynder
Din løsning...
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.