Wichtig: Welche Fehler treten auf

[Hans Schmucker]

Bei diesem Test sollte man wirklich beachten welche Fehler er findet und wie sich Fehler addieren. Zum Vergleich verschiedener Browser ist er eigentlich wirklich nicht zu gebrauchen, da es keine sinnvolle Gewichtung gibt: Das Zuweisungen auf reservierte Wörter möglich sind produziert z.B. schon allein 29 Fehler.

Die meisten Fehler im Firefox fußen darauf, dass er versucht fehlerhaften Code doch noch irgendwie zum laufen zu kriegen.

Und bevor die Flash Diskussion auch hier los geht. Actionscript verhält sich auf verschieden Platformen auch nicht 100%ig gleich.

[highrider]

Hans Schmucker schrieb:
--------------------------------------------------------------------------------

> Die meisten Fehler im Firefox fußen darauf, dass er versucht fehlerhaften
> Code doch noch irgendwie zum laufen zu kriegen.

Was für Fehler? Fehler im Standard?

highrider

[Hans Schmucker]

Fehler bei dieser Testsuite. Aber ja, einige könnte man auch als Fehler im Standard beschreiben. Firefox hat einige Fehler selbst "gefixt" durch Javascript 1.8, aber das entspricht natürlich nicht ECMA.
Bei anderen Sachen vergibt er einfach nur zu großzügig was wohl damit zu begründen ist, das Firefox versucht mit dem MSIE kompatibel zu sein, was grundsätzlich heißt fehlerhaften Code zu interpretieren.

P.S. Javascript 1.8 ist natürlich nicht standardmäßig aktiviert, allerdings verwendet Firefox für 1.8 und ECMA weitestgehend den selben Parser, daher beeinflussen sie sich gegenseitig doch ganz erheblich



1 mal bearbeitet, zuletzt am 12.03.10 18:03 durch Hans Schmucker.

[Ultrasonic]

Ja, Fehler im Standard.

Der Standard schreibt zum Beispiel vor, dass Schlüsselwörter wie "int", "boolean", "goto" (!!), "abstract" etc. zwar existieren, also nicht als Bezeichner von Variablen verwendet werden dürfen, aber keinerlei Bedeutung haben.

Wenn ein Programmierer diese Schlüsselwörter nun aber als Variablenbezeichner verwendet, müsste der standardkonforme Parser einen Fehler melden.

Das ist natürlich lächerlich. Es ist nämlich unmöglich diese Schlüsselwörter nachträglich mit Bedeutung zu füllen. Dadurch würde eine komplett andere Sprache entstehen.

[UltraKlatsche]

Ultrasonic schrieb:
--------------------------------------------------------------------------------
> Es ist nämlich unmöglich diese
> Schlüsselwörter nachträglich mit Bedeutung zu füllen.

So ein Unsinn.

[darkfate]

> Das ist natürlich lächerlich. Es ist nämlich unmöglich diese
> Schlüsselwörter nachträglich mit Bedeutung zu füllen. Dadurch würde eine
> komplett andere Sprache entstehen.

Wenn du wüsstest was C/C++ in ihrer Laufbahn miterleben mussten :)

[Ultrasonic]

Hmm... Ja, aber echt mal. Bei JavaScript kriegt man beim Abfragen des Datentypes einer Zahl gerade mal ein "number" als String zurück. Und wenn man der Variablen dann ne Kartoffel zuweist ist das auch kein Problem.

[Hans Schmucker]

Ultrasonic schrieb:
--------------------------------------------------------------------------------
> Hmm... Ja, aber echt mal. Bei JavaScript kriegt man beim Abfragen des
> Datentypes einer Zahl gerade mal ein "number" als String zurück. Und wenn
> man der Variablen dann ne Kartoffel zuweist ist das auch kein Problem.


*smile* Du darfst es auch gern double nennen, das ist es nämlich. Aber dich wird freuen, dass WebGL quasi durch die Hintertür mehr nummerische Typen mitbringt (ich mach hier gerade mal Copy/Paste von meinen Makros, keine Lust es noch mal auszutippen):

#define mUInt8Array(init) (new WebGLUnsignedByteArray(init))
#define mInt8Array(init) (new WebGLByteArray(init))
#define mUInt16Array(init) (new WebGLUnsignedShortArray(init))
#define mInt16Array(init) (new WebGLShortArray(init))
#define mUInt32Array(init) (new WebGLUnsignedIntArray(init))
#define mInt32Array(init) (new WebGLIntArray(init))
#define mFloatArray(init) (new WebGLFloatArray(init))

[Hans Schmucker]

Das mit den reservierten Wörtern hat schon seinen Sinn, aber man kann sich leider, leider nicht nur an die Standards halten wenn man auf einen Markt dringt, der schon von anderen dominiert wird.

Firefox ist als Konkurrenz zu MSIE groß geworden, und das bedeutete nun mal, dass Kompatibilität relativ weit oben auf der Liste stand. And da das zuweisen auf reservierte Wörter etwas ist, was die Ausführung nach Standard geschriebener Scripts nicht behindert, aber die Ausführung von MsJScript erlaubt, wurde es eben auch Spidermonkey beigebracht.

[unnu]

Hans Schmucker schrieb:
--------------------------------------------------------------------------------
> Bei diesem Test sollte man wirklich beachten welche Fehler er findet (...)

Nö. Als Entwickler stehe ich da auf dem Standpunkt 'Ein Fehler ist ein Fehler zuviel'.

Das mal unabhängig davon das ich Opera schon seit den Zeiten verwende als ich noch dafür bezahlt habe und ja, er war es mir wert und wäre es mir immer noch sollten die mal knapp bei Kasse sein.

Das Problem ist nämlich fängt man an Fehler zu gewichten, also ausserhalb der Verantwortung der Entwicklungsabteilung, gewichtet jeder so das er möglichst gut aussieht. Am Ende hat man dann 10 Browser mit 10 * 100 Fehlern und keiner davon muss beseitigt werden da ja vollkommen irrelevant gegenüber den 900 der jeweils anderen.

[Hans Schmucker]

Du, ganz ehrlich, du hast noch nie mit Standards gearbeitet die bereits in Gebrauch sind. Eine Änderung zieht Folgen nach sich und du musst entscheiden: soll es dem Standard 100% entsprechen, aber bei 3% der Scripts abschmieren, oder machen wir eine Erweiterung die die Ausführung standardkonformer Scripts in keiner Weise verhindert, uns aber die 3% auch ausführen lässt? Dein Idealismus in allen Ehren, aber was bringt's wenn die Nutzer wegrennen weil nichts funktioniert?

[Ultrasonic]

Tatsächlich Hintertür. Aber das ist genau das, was ich meine. Bevor in JavaScript richtig primitive Datentypen eingeführt werden, kommen weitere vordefinierte Objekte.

[MESH]

Hans Schmucker schrieb:
--------------------------------------------------------------------------------
>Dein Idealismus in allen Ehren, aber was bringt's wenn die
> Nutzer wegrennen weil nichts funktioniert?

Man könnte es auch so sehen das man dann als entwickler gezwungen ist standardkonform zu schreiben damit man seine anwendung noch los wird, da anwendungen die sich nicht an die standards halten nicht ordentlich laufen und somit von niemanden genutzt würden.

[Hans Schmucker]

Das Problem ist, das du im Web viel Legacy-Content hast, der von niemandem mehr betreut wird. Der muss auch noch laufen. Ansonsten installieren die Leute IETab und wir haben nichts gewonnen.

[Hans Schmucker]

Zum Thema Standardkonformität neuen Codes... ganz ehrlich, ich hoffe mal das die Leute nicht nur in IE und Firefox testen. Opera insbesondere nimmt hier eine besondere Katalysatorrolle ein, indem Leute gezwungen werden neuen Code sauber zu schreiben.
Man mag es mögen oder nicht, aber in der Browserlandschaft gibt es verschiedene Rollen: Internet Explorer als Abwärtskompatibilitäts-Monster, Firefox als Mainstream Browser der mit Standard-Code und mit Legacycontent umgehen kann, Opera als Browser ohne Kompromisse.

[GodsBoss]

Ich sehe das differenzierter: Einen Fehler, der ein vom Standard abweichendes Verhalten verursacht, halte ich für schlimmer als einen Fehler, bei dem nicht konformer Code noch ausgeführt wird, wie auch immer.

Die Fehler der zweiten Kategorie sollten nämlich leicht zu finden sein, spätestens wenn mehrere Engines zum Testen genutzt werden (unwahrscheinlich, dass alle alles exakt gleich ausbügeln).

Die der ersten Kategorie sind hingegen richtig hässlich, weil man bei ausreichender Verbreitung einer solchen Engine anfangen muss, Einschränkungen zu machen und kann sich womöglich nur auf mehr oder weniger lückenhafte Informationen der Hersteller verlassen.

Reden ist Silber, Schweigen ist Gold, meine Ausführungen sind Platin.