Eine Möglichkeit, eine Programmiersprache zu klassifizieren, ist die Betrachtung, wie stark oder schwach typisiert sie ist. Hier bedeutet „typisiert“, ob Variablen zur Kompilierungszeit bekannt sind. Ein Beispiel hierfür wäre ein Szenario, in dem eine Ganzzahl (1) zu einem String hinzugefügt wird, der eine Ganzzahl enthält ("1").
result = 1 + "1";
Der String, der eine Ganzzahl enthält, könnte unbeabsichtigt aus einer komplizierten Logik mit vielen beweglichen Teilen generiert worden sein. Er könnte auch absichtlich aus einer einzigen Quelle der Wahrheit generiert worden sein.
Trotz der Konnotationen, die die Begriffe „schwach“ und „stark“ implizieren, ist eine stark typisierte Programmiersprache nicht unbedingt besser als eine schwach typisierte. Es kann Szenarien geben, in denen Flexibilität mehr benötigt wird als Starrheit und umgekehrt. Wie bei vielen Aspekten der Programmierung hängt die Antwort von mehreren externen Kontexten ab (d. h. „es kommt darauf an“).
Das andere Interessante ist, dass es keine formale Definition dafür gibt, was starke oder schwache Typisierung ausmacht. Das bedeutet, dass die Wahrnehmung, was als stark oder schwach typisierte Sprache gilt, von Person zu Person unterschiedlich ist und sich im Laufe der Zeit ändern kann.
TypeScript
JavaScript gilt als schwach typisierte Sprache, und diese Flexibilität trug zu seiner frühen Verbreitung im Web bei. Da sich das Web jedoch weiterentwickelt und industriellisiert hat, sind die Anwendungsfälle für JavaScript komplexer geworden.
Erweiterungen wie TypeScript wurden entwickelt, um dabei zu helfen. Betrachten Sie es als ein „Plugin“ für JavaScript, das dem Sprachumfang starke Typisierung hinzufügt. Dies hilft Programmierern, komplizierte Setups zu bewältigen. Ein Beispiel hierfür könnte eine datenintensive Single-Page-Anwendung für den E-Commerce sein.
TypeScript ist derzeit in der Webentwicklungsbranche sehr beliebt, und viele neue Projekte verwenden standardmäßig TypeScript, wenn sie mit der Einrichtung beginnen.
Kompilierungszeit
Kompilierungszeit ist der Moment, in dem eine Programmiersprache in Maschinencode umgewandelt wird. Sie ist ein Vorläufer der Laufzeit, dem Moment, in dem der Maschinencode vom Computer ausgeführt wird.
Wie bei vielen Dingen im Web ist die Kompilierungszeit etwas knifflig. Ein Setup, das TypeScript verwendet, fügt JavaScript-Code-Komponenten zusammen und kompiliert sie zu einer einzigen JavaScript-Datei, die der Browser lesen und ausführen kann.
Die Zeit, zu der die Komponenten kompiliert werden, ist, wenn sie alle zusammengefügt werden. TypeScript fungiert als eine Art Aufseher und wird Sie anmeckern, wenn Sie versuchen, die von Ihnen eingerichteten Typkonventionen vor dem Zusammenfügen zu brechen.

Die zusammengefügte JavaScript-Datei wird dann vom Browser übernommen, der seine eigene Kompilierungszeit hat. Die Kompilierungszeit des Browsers ist stark variabel und hängt davon ab
- dem Gerät, auf dem sich der Browser befindet,
- welche anderen Arbeiten der Browser gerade erledigt, und
- welche anderen Arbeiten die anderen Programme des Geräts gerade erledigen.
TypeScript wird vom Browser nicht direkt verwendet, aber seine Präsenz ist spürbar. JavaScript ist fragil. TypeScript hilft bei dieser Fragilität, indem es versucht, Fehler im Code-Editor im Vorfeld zu verhindern. Dies verringert die Wahrscheinlichkeit, dass Fehler in dem von den Browsern gelesenen JavaScript auftreten – Fehler, die dazu führen würden, dass JavaScript auf der Website oder Webanwendung, die eine Person nutzt, nicht mehr funktioniert.
CSS
CSS ist eine deklarative, domänenspezifische Programmiersprache. Sie ist auch stark typisiert. Zum größten Teil bleiben Werte in CSS so deklariert, wie sie geschrieben wurden. Wenn ein Wert ungültig ist, verwirft der Browser die gesamte Eigenschaft.
Typen in CSS
Die Liste der Typen in CSS ist umfassend. Sie sind
Textuelle Typen
- Global definierte Schlüsselwörter
initialinheritunsetrevert
- Benutzerdefinierte Identifikatoren, die speziell für Dinge verwendet werden, wie z. B. die Angabe eines Namens für die
grid-area - Strings, wie z. B.
"hallo" - URLs, wie z. B.
https://css-tricks.de/ - Mit Bindestrichen versehene Identifikatoren (
--), die zur Erstellung benutzerdefinierter Eigenschaften verwendet werden (mehr dazu gleich)
Numerische Typen
- Ganzzahlen, bei denen es sich um Dezimalzahlen von 0–9 handelt
- Reelle Zahlen, wie z. B.
3.14 - Prozentangaben, wie z. B.
25% - Dimensionen, eine Zahl mit angehängter Einheit, wie z. B. (
100pxoder3s) - Verhältnisse, wie z. B.
16/9 - flex, eine variable Länge für die Berechnung von CSS-Grids
Mengentypen
- Längen
- Absolute Längen, wie z. B. Pixel oder Zentimeter
- Relative Längen, wie z. B. Root-ems oder die Viewport-Höhe
- Zeit, wie z. B.
200ms
- Winkel, wie z. B.
15deg - Zeit, wie z. B.
250ms - Frequenzen, wie z. B.
16Hz - Auflösung, wie z. B.
96dpi
Dimensionen und Längen mögen ähnlich erscheinen, aber Dimensionen können Prozente enthalten, Längen jedoch nicht.
Farbtypen
- Schlüsselwörter
- Benannte Farben, wie z. B.
papayawhip transparentcurrentColor
- Benannte Farben, wie z. B.
- RGB-Farben
- Hexadezimale Notation, wie z. B.
#FF8764 - RGB/RGBa-Notation, wie z. B.
rgba(105, 221, 174, 0.5)
- Hexadezimale Notation, wie z. B.
- HSL/HSLA-Farben, wie z. B.
hsl(287, 76%, 50%) - Systemfarben, wie z. B.
ButtonText
Bildtypen
- Image, was eine URL-Referenz zu einer Bilddatei oder einem Gradienten ist
color-stop-list, eine Liste von zwei oder mehr Farbstopps, die für die Gradientennote verwendet wirdlinear-color-stop, ein Farb- und Längen-Ausdruck, der zur Angabe eines Gradienten-Farbstopps dientlinear-color-hint, eine Längenprozentangabe zur Interpolation von Farbenending-shape, das ein Schlüsselwort entwedercircleoderellipsefür radiale Gradienten verwendet
2D-Positionierungstypen
- Schlüsselwörter
toprightbottomleftcenter
- Eine prozentuale Länge, wie z. B.
25%
Programmierung in CSS
Der Großteil der Programmierung in CSS besteht aus dem Schreiben von Selektoren, gefolgt von der Angabe einer Reihe von Eigenschaften und ihren erforderlichen Werten. Sammlungen von Selektoren verleihen Inhalten eine visuelle Form, ähnlich wie Sammlungen von JavaScript-Logik Features erstellen.
CSS hat Funktionen. Es kann Berechnungen, bedingte Logik, algorithmische Ausdrücke, Zustände und modulbasiertes Verhalten ausführen. Es verfügt auch über benutzerdefinierte Eigenschaften, die effektiv CSS-Variablen sind und es ermöglichen, Werte dynamisch zu aktualisieren. Man kann sogar FizzBuzz mit CSS lösen.
Wie andere Programmiersprachen gibt es auch eine „Meta“-Schicht mit unterschiedlichen Gedanken und Techniken, wie man Dinge organisieren, verwalten und pflegen kann.
Fehler werfen
Im Gegensatz zu anderen Programmiersprachen, bei denen der Code weitgehend im Verborgenen existiert, ist CSS hochgradig visuell. Sie sehen keine Warnungen oder Fehler in der Konsole, wenn Sie einen ungültigen Wert für eine Eigenschaftsdeklaration verwenden, aber Sie erhalten visuelle Darstellungen, die sich nicht wie erwartet aktualisieren.
Der Grund dafür ist, dass CSS resilient ist. Wenn die visuellen Darstellungen aufgrund einer falsch konstruierten Deklaration nicht aktualisiert werden, priorisiert CSS: die Anzeige von Inhalten um jeden Preis sicherstellen und alle anderen gültigen Deklarationen rendern, die es möglicherweise kann. Dies steht im Einklang mit den Designprinzipien der Sprache, den Prinzipien der Plattform und den übergeordneten Zielen der Mission des Webs.
Beweis
Lassen Sie uns anhand von drei Beispielen demonstrieren, wie die starke Typisierung in CSS die Leitplanken aufrechterhält: eines mit einer geradlinigen Eigenschaften-/Wertdeklaration, eines mit Berechnung und eines mit der Neudefinition einer benutzerdefinierten Eigenschaft.
Beispiel 1: Einfache Eigenschaften-/Wertdeklaration
Siehe den Pen Basic example von Eric Bailey (@ericwbailey) auf CodePen.
Für dieses Beispiel versteht der Browser die Deklaration „potato“ für border-style des Banners nicht. Beachten Sie, dass die anderen Eigenschaften-/Wertdeklarationen der .banner-Klassenauswahl vom Browser honoriert und gerendert werden, obwohl border-style einen Typenfehler aufweist. Dies ist ein Beispiel dafür, wie resilient CSS ist.
Die Deklaration border-style erwartet einen der folgenden Textuellen Styl-Typen
- Global definierte Schlüsselwörter oder ein
- Mit Bindestrichen versehener Identifikator für eine benutzerdefinierte Eigenschaft.
Wenn wir border-style auf einen gültigen, typisierten Wert wie dotted aktualisieren, rendert der Browser den Rand!
Beispiel 2: Berechnung
Die Funktion calc() in CSS erlaubt es uns, zwei Argumente und einen Operator zu nehmen, um ein berechnetes Ergebnis zu liefern. Wenn eines der Argumente keinen gültigen Typ verwendet, funktioniert die Berechnung nicht.
In diesem Pen erwartet die Eigenschaft font-size der p-Selektor einen Wert mit einem numerischen Dimensionstyp (z. B. 1.5rem). Die Berechnungsfunktion liefert jedoch einen ungültigen Typwert für die font-size-Eigenschaft. Das liegt daran, dass das zweite Argument der calc()-Funktion ein String ("2rem") und kein numerischer Dimensionstyp ist.
Aus diesem Grund fällt die Schriftgröße des Absatzes auf den nächstbesten anwendbaren übergeordneten Knoten zurück – die font-size von 1.5rem, die auf dem body-Element deklariert ist.
Das ist etwas ins Detail gehend, aber es lohnt sich, darauf hinzuweisen: Die Kombination zweier benutzerdefinierter Eigenschaften in einer calc()-Funktion kann Fehler verursachen. Während beide benutzerdefinierten Eigenschaften für sich allein gültig sein mögen, akzeptiert calc() keine Textuellen Typen, die mit Bindestrichen versehen sind. Denken Sie an ein Szenario, in dem wir versuchen, benutzerdefinierte Eigenschaften zu multiplizieren, die nicht übereinstimmende Einheiten enthalten, z. B. --big: 500px und --small: 1em.
Beispiel 3: Neudefinierte benutzerdefinierte Eigenschaft
Ähnlich wie JavaScript-Variablen können Werte benutzerdefinierter Eigenschaften neu definiert werden. Diese Flexibilität ermöglicht es beispielsweise, einfach dunkle Farbschemata für den Dark Mode zu erstellen.
Im :root-Selektor dieses CodePens habe ich eine benutzerdefinierte Eigenschaft --color-cyan mit dem Wert #953FE3 gesetzt. Dann habe ich in der .square-Klasse den Wert der benutzerdefinierten Eigenschaft --color-cyan auf top geändert. Obwohl top ein gültiger, typisierter Wert ist, ist es kein Typ, den background-color akzeptiert.
Beachten Sie, dass die aktualisierte benutzerdefinierte Eigenschaft auf .square beschränkt ist und andere Verwendungen nicht beeinflusst, wie z. B. den rechten Rand des Satzes „Don’t play to type“. Und wenn Sie die neu definierte benutzerdefinierte Eigenschaft aus .square entfernen, sehen Sie, wie die cyanfarbene Hintergrundfarbe zurückkehrt.
Auch wenn dies etwas konstruiert ist, dient es als Beispiel dafür, wie die Neudefinition von benutzerdefinierten Eigenschaften aus dem Ruder laufen kann, wenn man nicht vorsichtig ist.
Dieses Phänomen tritt in Projekten mit schlechter Kommunikation, größeren CSS-Codebasen und Situationen auf, in denen CSS-Präprozessoren verwendet werden, um benutzerdefinierte Eigenschaften in großem Maßstab zu erstellen.
Werkzeuge
Mit dem Wissen der Nachbetrachtung glaube ich, dass das Fehlen von Konsolenwarnungen für CSS ein Mangel ist und zu vielen negativen Wahrnehmungen der Sprache beigetragen hat.
Zu hoffen, dass ein Entwickler eine potenziell winzige visuelle Änderung bemerkt, ist zu viel verlangt und trifft ihn nicht dort, wo er sich mit den meisten seiner anderen täglichen Werkzeuge befindet. Es gibt ein paar Initiativen, von denen ich weiß, dass sie versuchen, dies anzugehen.
Erstens ist da stylelint, ein Linter, der speziell für CSS und CSS-ähnliche Präprozessorsprachen entwickelt wurde. Stylelint kann mit Code-Editoren, Task-Runnern, Kommandozeilentools und GitHub Actions integriert werden, um Ihr CSS unter Kontrolle zu halten. Dies ermöglicht es, Entwickler dort abzuholen, wo sie bereits sind.

Zweitens gibt es die ausgezeichnete Sammlung von CSS-Inspektionsoptionen in den Entwicklertools von Firefox. Insbesondere möchte ich auf die Möglichkeit hinweisen, ungenutztes CSS zu identifizieren. Dies ist äußerst hilfreich bei der Identifizierung von Selektoren, die möglicherweise mit einem Typenfehler in Konflikt geraten sind.

Zusammenfassung
CSS ist seit seiner Entstehung als Programmiersprache stark typisiert, und als Programmiersprache existiert sie schon sehr lange. Außerdem hat sie in letzter Zeit viel dazugelernt. Wenn Sie sich nicht informiert haben, gibt es einige neue, erstaunliche Funktionen.
Da stark typisiertes JavaScript immer beliebter wird, hoffe ich, dass es Entwicklern hilft, sich mit dem festen, aber flexiblen Ansatz von CSS vertrauter zu machen.
Vielen Dank an Miriam Suzanne für ihr Feedback.
Toller Artikel! Ich mag diesen pragmatischen Ansatz beim Lehren von CSS-Dingen wirklich. Du behandelst es als tatsächliche Programmiersprache und nicht als eine Reihe von Eigenschaften, die man anpassen kann, um seinen Text andersfarbig zu machen
Außer dass CSS keine Programmiersprache ist. Man kann kein Programm mit CSS erstellen. CSS ist eine Datensprache (wie Json oder YAML).
Diese Sichtweise ist so langweilig wie vorhersehbar.
Es mag langweilig sein, aber es ist Teil der Grundlage dieses Artikels.
Hier steht auf der offiziellen Website des WWW-Konsortiums: „Cascading Style Sheets (CSS) ist ein einfacher Mechanismus zum Hinzufügen von Stil (z. B. Schriftarten, Farben, Abstände) zu Webdokumenten.“ https://www.w3.org/Style/CSS/Overview.en.html
Und hier ist ein Artikel über Konfigurationsdateien
https://en.m.wikipedia.org/wiki/Configuration_file
CSS ist nur eine Reihe von Konfigurationsdateien für die Rendering-Engine.
So sehe ich das.
Man könnte es tatsächlich als eine solche betrachten.
Dies liegt daran, dass es die Markup-Struktur selbst als Eingabe hat und die Werte aus den Eigenschaften als Variablen. Es nimmt tatsächlich das ungestylte HTML auf und verwandelt es in eine sehr gut aussehende Webseite.
Aus diesem Grund sage ich meinen Studenten oft, dass das, was sich innerhalb der geschweiften Klammern befindet, eher als DIREKTIVEN denn als bloße machtlose Deklarationen betrachtet werden kann. Es ist wie beim Aufrufen einer Funktion in JS (natürlich führt hier der Browser die Direktive aus – bitte beachten Sie die imperative Bedeutung davon –, indem er einfach die Seite lädt, also nicht unbedingt durch ein vom Menschen verursachtes Ereignis auf dieser Seite ausgelöst, wie Hovern, Klicken, was auch immer).
Wir schreiben tatsächlich CSS-Code, der ausgeführt werden soll, nicht nur, um ihn in unserem Code-Editor anzusehen.
Dies trägt vielleicht dazu bei, dass CSS doch eine Programmiersprache ist. Es ist nicht nur etwas Präsentationsbedingtes wie ein Notizblocktext, bei dem eine Syntax andeuten könnte, dass man in ein anderes Dokument navigieren könnte, wenn man das erste (offensichtlich beziehe ich mich auf ein HTML-Dokument) in einem Browser öffnen würde. Es hat tatsächlich auch eine Art Laufzeit, wenn man so sagen kann, wenn der Browser beschließt, die Seite zu fließen (oder neu zu fließen). Und die Tatsache, dass es kaskadierend ist, beweist dies (der Browser füllt den Body von außen nach innen bei jedem Element, d. h. vom Elternteil zum Kind, daher gibt es eine strenge Reihenfolge bei der Ausführung, mit bedingter Logik / wenn dann / oder sonst / wie bei jeder anderen Sprache. Fakt ist, dass JS oder jede andere Sprache auch in kaskadierender Weise funktionieren (nichts Neues hier), weil man einen Variablenwert nicht richtig verwenden kann, bis er zugewiesen ist. Daher gibt es auch hier eine solide kaskadierende Logik im Hintergrund.
Daher ist CSS nicht nur präsentationsbezogen, so wie Gioconda auch nicht präsentationsbezogen ist, weil ein Maler die Farbe auf der Leinwand mischen musste, stimmst du nicht zu? Daher gab es eine Transformation (wie jede andere Programmiersprache uns erleichtern soll), und die Tatsache, dass CSS im Browser funktioniert, mindert seine Bedeutung nicht. Nebenbei bemerkt, sind alle Sprachen, die jemanden benötigen, der „hilft, damit sie funktionieren“ (d. h. sie kompilieren, bevor sie überhaupt Code daraus ausführen), nicht irgendwie geringere Bürger der Programmierwelt.
Ich könnte sagen, es ist sogar das Gegenteil.
@Eve Lassen Sie mich Ihnen ein Beispiel geben,
Nehmen wir an, wir haben ein Programm in JavaScript geschrieben und eine JSON-Datei für die Konfiguration (zum Speichern der Werte einiger Schlüsseleigenschaften) beibehalten. Das Ändern von Werten in diesem JSON kann die Ausgabe unseres Codes stark beeinflussen, aber das bedeutet nicht, dass JSON eine Programmiersprache ist.
Bevor dies zu weit geht, scheinen einige Leute Turing-Vollständigkeit mit Programmiersprache zu verwechseln. Wie im Beitrag verlinkt, sind domänenspezifische Sprachen (DSL) eine anerkannte Disziplin in der Informatik.
CSS, wie JSON, JavaScript, HTML usw., ist eine Reihe von Anweisungen, die man einem Compiler zuführt, um ein Ergebnis zu erhalten. Das ist Programmierung. Die Erstellung eines Programms ist nur eine von vielen Arten von Ausgaben, die eine Programmiersprache erreichen kann.
Wenn Sie CSS als Programmiersprache in Frage stellen, widersprechen Sie dem gesamten Feld der Informatik. Wenn Sie keinen Doktortitel in diesem Bereich haben, werde ich wahrscheinlich nicht zuhören.
Auch diese Sichtweise ist langweilig und mittelmäßig, und ich möchte ihr nicht wirklich mehr Zeit oder Aufmerksamkeit widmen. Eine weitaus bessere Frage ist, was haben Sie kürzlich in CSS getan, um die Unterhaltung voranzutreiben?
Selbst benutzerdefinierte Eigenschaften können einen Typ haben
https://developer.mozilla.org/en-US/docs/Web/CSS/@property
Es ist ziemlich neu und wird nur in Chromium-Browsern unterstützt.
Durch die Festlegung des Typs für eine benutzerdefinierte Eigenschaft wird der Browser auch in der Lage sein, Werte wie Hintergrundverläufe zu animieren. Sehen Sie sich die Beispiele an unter: https://web.dev/at-property/
Danke für den Beitrag! Es ist erwähnenswert, dass man auch in CSS eine Art Typkonvertierung erreichen kann. Hier sind ein paar Beispiele
* Cassie Evans wandelt eine Ganzzahl in einen String um mit
counter-reset()* Carter Li zeigt, wie man eine Gleitkommazahl in eine Ganzzahl umwandelt mit
calc()und@property.Es mag weitere mögliche Konvertierungen geben, ich bin mir nicht ganz sicher – aber ich verlasse mich oft darauf in meinen eigenen HTML/CSS-Diagramm-Experimenten (z. B. um Werte in einem gefälschten Tooltip anzuzeigen) [https://ffoodd.github.io/chaarts/pie-charts.html].
Ich stimme Ihrem Gesamtpunkt (CSS ist eine echte, typisierte Programmiersprache usw.) voll und ganz zu, aber ich wünschte, Sie hätten die Begriffe „schwach typisiert“ und „stark typisiert“ nicht verwendet. Sie können verwirrend und sogar irreführend sein.
„Schwach typisiert“ hat im Grunde zwei Definitionen
1: Eine Sprache, in der man mit den Bits, auf die die Variablen zeigen, alles machen kann, unabhängig von ihrem Typ. Assembler ist ein gutes Beispiel dafür. Man kann einen String erstellen und es ist egal, ob man Fließkommaoperationen darauf anwendet (obwohl man seltsame Ergebnisse erhalten kann). Das ist bei JavaScript nicht der Fall! Wenn man Typen mischt, konvertiert JavaScript sie entweder automatisch oder gibt Ihnen einen Fehler.
2: Eine Sprache, in der die Typen der Sprache zur Laufzeit dynamisch gesetzt werden können. Das bedeutet, dass jedes Mal, wenn Sie einer Variablen etwas zuweisen, sich ihr Typ ändern kann. Die Variablen haben immer noch einen Typ und sie prüfen den Typ oft zur Laufzeit! Wenn Sie Typen mischen, kann die Sprache sie in einigen Fällen automatisch konvertieren oder einen Fehler auslösen. Das ist es, was JavaScript tut.
Bessere, klarere und weniger kontroverse Terminologie ist „dynamisch typisiert“ und „statisch typisiert“. In dieser Terminologie ist JavaScript dynamisch typisiert, da seine Typen zur *Laufzeit* aufgelöst werden. Sie haben immer noch Typen und es erlaubt Ihnen nicht einfach, alles mit den Variablen zu tun, unabhängig von den Typen. Dann ist bei etwas wie TypeScript statisch typisiert, da seine Typen zur Kompilierungszeit aufgelöst werden.
Ich denke, nach dieser Definition ist CSS statisch typisiert, aber ich bin nicht wirklich qualifiziert, die Feinheiten von CSS zu kommentieren. In jedem Fall denke ich, es ist gut, eine Definition mit klaren Begriffen zu verwenden. Immer wenn jemand den Begriff „schwach typisiert“ verwendet, frage ich mich oft, welche Definition des Begriffs er verwendet (obwohl ich ziemlich sicher bin, dass Sie hier die zweite von mir erwähnte verwenden).
Starke/schwache Typisierung ist orthogonal zur statischen/dynamischen Typisierung. Ihre erste Definition ist schwache Typisierung. Ihre zweite Definition ist dynamische Typisierung. Ich würde JavaScript als dynamisch und schwach typisiert betrachten – es versucht wirklich hart, einen Wert in einen Typ zu konvertieren, aber es handelt sich immer noch um eine implizite Umwandlung. C ist ein interessantes Fallbeispiel – es ist statisch typisiert und nicht stark typisiert – zumindest was die Arithmetik betrifft. Es konvertiert automatisch zwischen Gleitkommazahlen und Ganzzahlen, was zu unbeabsichtigten Rundungsfehlern bei neuen Entwicklern führen kann.
Ich gebe zu, dass starke/schwache Typisierung nicht gut definiert ist, aber dynamische Typisierung ist es. Eine dynamisch typisierte Sprache führt die Typisierung zur Laufzeit durch, und eine statisch typisierte Sprache führt die Typisierung zur Kompilierungszeit durch.