© Andrew Rybalk/Shutterstock.com
Entwickler Magazin
Ein Blick unter die Haube des Typsystems in Swift

Streng, aber fair

Swift ist streng, was Typen angeht. Es ist nämlich eine statisch typisierte Sprache. Die Swift-Entwickler unter den Lesern haben bestimmt bereits die roten kleinen Kreise aus Xcode vor Augen - die Compilerfehler! Warum kommt es dazu, und weshalb hat man ab und an das Gefühl, Swift stehe bei der Entwicklung eher im Weg, anstatt den ohnehin schon steinigen Pfad in Richtung Ziel einfacher zu gestalten? Diese Fragen werden auf den folgenden Seiten durch einen Blick unter die Haube des Typsystems in Swift beantwortet.

Manuela Rink


Über die Zeit haben sich die eher losen Begriffe von „statischer vs. dynamischer“ bzw. „strenger vs. schwacher“ Typisierung rund um Programmiersprachen gefestigt. Aber was bedeuten sie denn nun genau? Alles dreht sich bei der Klassifizierung um Typen und darum, von welchem Typ Variablen und Konstanten sind. Doch im Grunde ist die Erklärung ganz einfach. Statisch typisierte Sprachen setzen bereits zur Kompilierzeit voraus, dass alle Typen definiert sind. Dynamisch typisierte Sprachen sind lockerer und überprüfen das erst zur Laufzeit. Nun haben beide Ansätze Vor- und Nachteile: gesunde Einschränkung vs. grenzenlose (Fehler-)Möglichkeiten?

Die statische Typisierung bewahrt den Entwickler und seine Anwendung bereits im Vorfeld vor mysteriösen Abstürzen und Fehlverhalten, frei nach dem Motto „fail fast, fail cheap“. Da man aber klar definieren muss, welcher Wert von welchem Typ ist, hat man als Entwickler oftmals das Gefühl der künstlichen Einschränkung. Es ist durchaus mühsam, bereits im Vorfeld für jeden verwendeten Wert den Typ festzulegen und im Programmablauf beispielsweise mit Typecasting sicherzustellen, dass er auch eingehalten wird.

Anders verhält es sich mit dynamischer Typisierung. Hier besteht nicht die Notwendigkeit, alle Typen zu kennen – man weist einfach Werte auf Variablen zu, ohne sich im Detail über die Typen im Klaren sein zu müssen. Das Verfassen von Quellcode ist so etwas freier, da man nicht ständig auf die Finger geklopft bekommt, wenn z. B. ein Float-Wert nicht mit einer String-Variablen zusammenpasst. Erst wenn das Programm ausgeführt wird, müssen die Werte und Typen kompatibel sein, was unter Umständen allerdings zu Fehlern und Abstürzen führen kann.

Swift zählt klar zu der Gruppe der statisch typisierten Sprachen, was Apple selbst „typsicher“ nennt. Der Entwickler soll sich sicher sein können, dass alle verwendeten Werte auch einen definierten Typ aufweisen – zu jeder Zeit. Somit hilft diese Art von Typsicherheit, Fehler im Programm frühestmöglich im Entwicklungsprozess zu finden, nämlich bereits da, wo der Code geschrieben und kompiliert wird. Dies soll wiederum Laufzeitfehlern jede Daseinsberechtigung entziehen.

Typbasierte Fehler, die sich während der Entwicklung bzw. noch beim Schreiben des Quellcodes einschleichen, werden in Xcode visuell anschaulich dargestellt. Das passiert in der Regel auch erstaunlich schnell. Kaum hat man z. B. einer Variablen einen unpassenden Wert zugewiesen, wird man sofort durch ein Banner inklusive ein...

Entwickler Magazin
Ein Blick unter die Haube des Typsystems in Swift

Streng, aber fair

Swift ist streng, was Typen angeht. Es ist nämlich eine statisch typisierte Sprache. Die Swift-Entwickler unter den Lesern haben bestimmt bereits die roten kleinen Kreise aus Xcode vor Augen - die Compilerfehler! Warum kommt es dazu, und weshalb hat man ab und an das Gefühl, Swift stehe bei der Entwicklung eher im Weg, anstatt den ohnehin schon steinigen Pfad in Richtung Ziel einfacher zu gestalten? Diese Fragen werden auf den folgenden Seiten durch einen Blick unter die Haube des Typsystems in Swift beantwortet.

Manuela Rink


Über die Zeit haben sich die eher losen Begriffe von „statischer vs. dynamischer“ bzw. „strenger vs. schwacher“ Typisierung rund um Programmiersprachen gefestigt. Aber was bedeuten sie denn nun genau? Alles dreht sich bei der Klassifizierung um Typen und darum, von welchem Typ Variablen und Konstanten sind. Doch im Grunde ist die Erklärung ganz einfach. Statisch typisierte Sprachen setzen bereits zur Kompilierzeit voraus, dass alle Typen definiert sind. Dynamisch typisierte Sprachen sind lockerer und überprüfen das erst zur Laufzeit. Nun haben beide Ansätze Vor- und Nachteile: gesunde Einschränkung vs. grenzenlose (Fehler-)Möglichkeiten?

Die statische Typisierung bewahrt den Entwickler und seine Anwendung bereits im Vorfeld vor mysteriösen Abstürzen und Fehlverhalten, frei nach dem Motto „fail fast, fail cheap“. Da man aber klar definieren muss, welcher Wert von welchem Typ ist, hat man als Entwickler oftmals das Gefühl der künstlichen Einschränkung. Es ist durchaus mühsam, bereits im Vorfeld für jeden verwendeten Wert den Typ festzulegen und im Programmablauf beispielsweise mit Typecasting sicherzustellen, dass er auch eingehalten wird.

Anders verhält es sich mit dynamischer Typisierung. Hier besteht nicht die Notwendigkeit, alle Typen zu kennen – man weist einfach Werte auf Variablen zu, ohne sich im Detail über die Typen im Klaren sein zu müssen. Das Verfassen von Quellcode ist so etwas freier, da man nicht ständig auf die Finger geklopft bekommt, wenn z. B. ein Float-Wert nicht mit einer String-Variablen zusammenpasst. Erst wenn das Programm ausgeführt wird, müssen die Werte und Typen kompatibel sein, was unter Umständen allerdings zu Fehlern und Abstürzen führen kann.

Swift zählt klar zu der Gruppe der statisch typisierten Sprachen, was Apple selbst „typsicher“ nennt. Der Entwickler soll sich sicher sein können, dass alle verwendeten Werte auch einen definierten Typ aufweisen – zu jeder Zeit. Somit hilft diese Art von Typsicherheit, Fehler im Programm frühestmöglich im Entwicklungsprozess zu finden, nämlich bereits da, wo der Code geschrieben und kompiliert wird. Dies soll wiederum Laufzeitfehlern jede Daseinsberechtigung entziehen.

Typbasierte Fehler, die sich während der Entwicklung bzw. noch beim Schreiben des Quellcodes einschleichen, werden in Xcode visuell anschaulich dargestellt. Das passiert in der Regel auch erstaunlich schnell. Kaum hat man z. B. einer Variablen einen unpassenden Wert zugewiesen, wird man sofort durch ein Banner inklusive ein...

Neugierig geworden?


   
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang