Autor |
Nachricht |
rgerhards
|
|
Titel: Globale Sichtbarkeit von Datentypen
Verfasst am: 20.10.2008, 21:09 Uhr
|
|
Anmeldung: 25. Sep 2006
Beiträge: 688
|
|
Anmerkung: "Global" ist eigentlich nicht ganz korrekt. Genau handelt es sich um Definitionen, die auf höherer Ebene als die aktuelle getroffen wurden. Der Einfachheit halber wird hier aber einfach von "global" gesprochen, was bei einfachen Aufgaben auch korrekt ist.
Auf globale Variablen soll (aus guten Gründen) nicht in Prozeduren und Funktionen zugegriffen werden. Für Typen gilt diese Restriktion nicht. Es kommt hin und wieder die Frage auf, warum das denn so ist und ob das überhaupt sinnvoll ist. Hier möchte ich eine Begründung aus meiner Sicht liefern.
Bei Typen ist globale Sichtbarkeit meiner Meinung nach eine Grundvoraussetzung. Warum? Wenn ich den "gleichen" Typen an zwei verschiedenen Stellen definieren würde, so wären es ja keine identischen Typen, sondern zwei verschiedene: eben a) der Typ der an Stelle 1 definiert wurde und b) die gleichnamige Typ, der an Stelle 2 (also einem anderen Kontext) definiert wurde. Damit wären aber auf einmal keine Typgleichen Variablen mehr möglich und man könnte folglich auch nichts mehr ohne implizite Typanpassung übergeben.
Man könnte jetzt sagen: gleicher Name - gleicher Typ und den Kontext ignorieren. Dann hat man aber nichts anderes gemacht, als letztlich doch globale Sichtbarkeit bewirkt und obendrein die Möglichkeit genommen, gleichnamige Typen in verschiedenen Kontexten zu definieren (was eh ne blöde Idee ist, aber immerhin...). Ein schwerwiegenderer Defekt einer solche Lösung wäre, dass man nun überall identische Definitionen schreiben müsste, obwohl der Typ per Definition doch der gleiche wäre.
Diese Regel wäre somit sinnlos, würde unnütz Arbeit verusachen und wäre obendrein eine grosse Fehlerquelle. |
|
|
|
|
|
aschunk
|
|
Titel: Globale Sichtbarkeit von Datentypen
Verfasst am: 30.11.2008, 09:47 Uhr
|
|
Anmeldung: 03. Okt 2008
Beiträge: 313
|
|
Soweit ich mich erinnere unterscheidet man in prozeduralen Programmiersprachen traditionell zwischen global und lokal, wobei lokal ja nur bedeutet,
dass eine Variable in einem bestimmt Kontext sichtbar ist.
Auch in Java oder C++ gibt es das Konzept von globalen und lokalen Variablen.
Das Problem dabei ist ja, dass mein zum Beispiel eine Variable, die man schon global - also zum Beispiel Programmglobal wie in Pascal oder Klassenglobal wie in Java - definiert hat und nun plötzlich in einem Block oder einer Schleife diese Variable noch mal verwenden möchte.
Das Problem tritt häufig bei sogenannten Laufvariablen auf wie i, j, k usw. die man auch im Programm oder in einer Klasse global verwendet.
Meines Erachtens ist es hier besesr, bei globalen Variablen sprechende Namen zu benutzen und einfache Variablen für Laufvariablen oder lokale Kontexte zu verwenden. |
|
|
|
|
|
aschunk
|
|
Titel: Globale Sichtbarkeit von Datentypen
Verfasst am: 30.11.2008, 09:47 Uhr
|
|
Anmeldung: 03. Okt 2008
Beiträge: 313
|
|
Dieser Thread würde glaube ich besser in das Forum imperative Programmierung passen. |
|
|
|
|
|
rgerhards
|
|
Titel: Globale Sichtbarkeit von Datentypen
Verfasst am: 30.11.2008, 09:51 Uhr
|
|
Anmeldung: 25. Sep 2006
Beiträge: 688
|
|
Übersehe ich etwas: der steht doch in imperative Programmierung?
Zum inhaltlichen Kommentar: klar, globale Variablen sollten nur verwendet werden, wenn es sehr gute Gründe dafür gibt. Und sie sollten auf jeden Fall sprechend sein. Meiner Meinung nach sollten Namenskonflikte grundsätzlich vermieden werden. |
|
|
|
|
|
Loki000
|
|
Titel:
Verfasst am: 18.12.2014, 10:47 Uhr
|
|
Anmeldung: 18. Dez 2014
Beiträge: 1
|
|
Man könnte jetzt sagen: gleicher Name - gleicher Typ und den Kontext ignorieren. Dann hat man aber nichts anderes gemacht, als letztlich doch globale Sichtbarkeit bewirkt und obendrein die Möglichkeit genommen, gleichnamige Typen in verschiedenen Kontexten zu definieren (was eh ne blöde Idee ist, aber immerhin...). Ein schwerwiegenderer Defekt einer solche Lösung wäre, dass man nun überall identische Definitionen schreiben müsste, obwohl der Typ per Definition doch der gleiche wäre. |
_________________ NAT
|
|
|
|
|
|