Jag undrar om det finns någon workaround, så jag slipper lägga all kod som strular i eval.
try - catch räcker inte för att fånga parse errors.
Sedan är det alltid kul med feed-back på en sån här grej. Tanken är att det skall resultera i buggrapporter till alla webbläsartillverkare. (Alla buggar på något sätt här!)
Jag försökte lite med att få MSIE att sluka getter-testet på rad 103.
Tyvärr så vägrar scriptet att exekvera så fort man använder den "främmande" syntaxen. :(
Hm, intressant sida. Vad är ändamålet? Ren buggrapportering bara? :)
För det första bör du använda _defineGetter_ / _defineSetter_ just av denna anledning. För det andra verkar varken setters/getters eller konstanter vara standard enligt ECMA, utan verkar vara ett påhitt av Mozilla.
Kolla själv i specen: http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf
Jag försökte lite med att få MSIE att sluka getter-testet på rad 103.
Tyvärr så vägrar scriptet att exekvera så fort man använder den "främmande" syntaxen. :(
Hm, intressant sida. Vad är ändamålet? Ren buggrapportering bara? :)
Jag märker detsamma. Det blir således att skriva om testet med eval. Suck.
Ändamål:
1. Tillfredsställa min nyfikenhet.
2. Buggrapportering
3. En mer väldefinierad standard för HTML 5. Jag har börjat före en diskussion på WHATWG:s lista om krav man bör ställa på webbläsarna.
Ex. Om man som Safari och G Chrome exekverar skript deklarerat med language="javascript17" - skall man då inte också erbjuda fullgott stöd för JavaScript 1.7? Skall inte sådana krav ställas i spec?
4. JavaScript 1.7+ har en opt-in syntax för let och yield. Det påverkar ECMAScript harmony och ev. 3.1. Jag har påbörjat en diskussion kring detta också på den mailinglistan. Också till det behöver jag underlag.
För det första bör du använda _defineGetter_ / _defineSetter_ just av denna anledning. För det andra verkar varken setters/getters eller konstanter vara standard enligt ECMA, utan verkar vara ett påhitt av Mozilla.
Kolla själv i specen: http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf
Tack. Jag har lusläst spec:en. Nu handlar det dock om framtiden. Många "påhitt" av Mozilla är på väg att tas upp i ECMAScript 3.1, andra kommer i "Harmony".
Mozilla har enligt standarden rätt att utveckla JavaScript som ett "superset" av ECMAScript. ECMAScript standarden är i princip alltid ett efterarbete som innebär formalisering av de facto-standarder.
_defineGetter_ kanske tar mig bort från att exekveringen slutar i MSIE (skall testa det), men jag vill kunna pröva all slags syntax i mitt test.
Ett förslag är att dela upp testet i flera steg, där varje steg sker i en separat script-tagg. Då kan du logga om t ex koden körs till att börja med, och sedan vilket värde den får. Här är ett enkelt testcase:
<script type="text/javascript">
key="setters";
testresults=[];
testresults[key]=0;
</script>
<script type="text/javascript">
testresults[key] = 1; // Status 1: The tag was parsed
o = {a:7, get b() {return this.a+1; }};
testresults[key] = 2; // Status 2: The init code was executed
</script>
<script type="text/javascript">
if ( 'undefined' != typeof o && o.b == 8 ) {
testresults[key] = 3; // Status 3: The value was returned correctly
}
</script>
<script type="text/javascript">
//alert(typeof o.b)
alert(testresults[key])
</script>
Du kommer dock uppenbarligen inte runt problemet att IE inte kommer att acceptera kod som den tycker är syntaktiskt felaktig.
För övrigt tycker jag att sådant här är intressant. Jag funderar på att göra ett liknande test som också innehåller prestandamätning.
264 ms totalt · 4 externa anrop · v20260731065814-full.5386d3bf
