Diskussion:Statische Typisierung

aus Wikipedia, der freien Enzyklopädie
Dies ist die aktuelle Version dieser Seite, zuletzt bearbeitet am 8. Juni 2012 um 13:55 Uhr durch imported>Daniel5Ko(823851) (→‎falsche Definition?: +Hinweis auf Punkt 11.4.3 in ECMA 262.).
(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)

Stackvariablen in dynamisch typisierten Sprachen

Ich hab mal folgenden Punkt entfernt:

  • Der von Variablen benötigte Speicherplatz (Größe und bei globalen Variablen auch die Adresse) kann bereits vom Compiler festgelegt werden. Dadurch können Variablen global oder auf dem Stack angelegt werden, statt auf dem Heap (welcher mehr Verwaltungsaufwand benötigt).

Der erste Satz ist noch OK, fällt für mich aber unter Optimierung. Der zweite ist entweder falsch oder sehr missverständlich. Dadurch werden keine Variablen global. Auch können durchaus dynamisch typisierte Sprachen den Stack verwenden. Sie können nicht wie statisch typisierte den Stackframe beim Prozeduraufruf setzen, sondern müssen diesen bei jeder neuen Variabelen vergrößern, was ineffizienter ist, aber natürlich kann auch der Stack verwendet werden und ich denke mal das machen die Interpreter auch. --Der Hâkawâti 22:16, 12. Nov. 2009 (CET)

falsche Definition?

Die jetzige Definition verlangt, dass es einen Unterschied zwischen "Compile time" und "Run time" gibt. Das hieße dann aber, dass bei rein interpretierten Sprachen keine statische Typisierung möglich wäre. Das bezweifle ich.
Meines Wissens meint "statische Typisierung" dass der Datentyp einer Variablen/eines Objekts während ihrer gesamten Lebensdauer gleich bleibt (=statisch ist), während er sich bei "dynamischer Typisierung" jederzeit (nach den Regeln der jeweiligen Sprache) ändern kann.
Bin ich mit dieser Auffassung ganz allein? --RokerHRO (Diskussion) 00:20, 4. Jun. 2012 (CEST)

nein, klingt durchaus logisch. Für mich bedeutet „statische Typisierung“ das gleiche wie „lexikalische Typisierung“, und beides heisst, dass die Typinformation allein durch Inspektion des Programmtexts gewonnen werden kann, ohne einen Gedanken daran zu verschwenden, was während des Programmlaufs eventuell passiert. Das ist aber äquivalent zu der von dir gewählten Formulierung, dass der Typ einer jeden Entität während seiner gesamten Lebensdauer gleich bleibt. -Herbert Klaeren (Diskussion) 09:31, 4. Jun. 2012 (CEST)
Wieso vermischst du Daten und Programmsymbole (wg. Zitat: "einer Variablen/eines Objekts")? Da ist doch der entscheidende Knackpunkt:
Statische Typen befinden sich an Variablen und dgl., und dynamische Typen an den Laufzeit-Werten als echte Datenbestandteile.
In einigen Sprachen gibt's laut ihrer eigenen Definition nur einen statischen Typ - dazu würde z.B. Python gehören. (Das spricht allerdings nicht dagegen, dass man trotzdem Programme bauen kann, die unterschiedliche und genauere statische Typen finden können, und dass man solche Teilprogramme in einen Python-Interpreter zwecks Optimierung o.ä. einbauen könnte.)
In anderen Sprachen gibt es nur einen einzigen dynamischen Typ (weswegen der gerade nicht zu einem Datenbestandteil gemacht oder überhaupt erwähnt werden muss). Dazu gehört zum Beispiel Haskell.
In vielen Sprachen koexistieren und interagieren statische und dynamische Typsysteme. Das sind vor allem solche mit vorhandenem statischen Typsystem und OOP-Features. (C++, Java, C#, Scala, Delphi, ...). Die Interaktion ist nicht-trivial, wie man z.B. an der Existenz eines Papers wie http://homepages.inf.ed.ac.uk/wadler/papers/blame/blame.pdf sieht.
--Daniel5Ko (Diskussion) 03:51, 8. Jun. 2012 (CEST)
Ich habe "Variable/Objekt" geschrieben, weil meine Aussage für beides gilt. Es gibt schließlich Objekte, die zu keiner Variablen "gehören". Vielleicht hätte ich "Funktion/Objekt" schreiben sollen. Spielt für den Rest meiner Aussagen aber keine Rolle.
Während der Lebensdauer eines Objektes ist sein Typ konstant. Funktionen haben keine Lebensdauer i.e.S. Aber ihr Typ ist während der gesamten Programmlaufzeit konstant.
--RokerHRO (Diskussion) 10:15, 8. Jun. 2012 (CEST)
Nenne mal Beispiele von nach deiner Sichtweise dynamisch typisierten Sprachen (Python kann ja z.B. nicht dazugehören). --Daniel5Ko (Diskussion) 10:46, 8. Jun. 2012 (CEST)
JavaScript: var i=5; /* i ist eine zahl */ i="foo"; /* i ist jetzt ein String */
--RokerHRO (Diskussion) 12:52, 8. Jun. 2012 (CEST)
Die Typen von 5 und von "foo" haben sich nicht geändert. Was sich geändert hat, ist der dynamische Typ des Inhalts von i, und zwar weil der Inhalt ausgetauscht wurde (und dynamische Typen an Laufzeitwerten hängen).
Das gleiche Beispiel in Java, um eine Beziehung zu statischen Typen herzustellen: Object i=5; i="foo";.
--Daniel5Ko (Diskussion) 13:38, 8. Jun. 2012 (CEST)
Ich sprach nicht von Java, sondern von JavaScript. Und dort liefert der typeof()-Operator für i jeweils ein anderes Ergebnis. Also ändert sich der Typ von i während der Lebenszeit von i, also dynamisch typisiert --RokerHRO (Diskussion)
Ich sprach von deinem Beispiel und von einer Übersetzung nach Java. JavaScripts typeof kümmert sich um dynamische Typen. Analoges gibt's in Java in Form von class casts, instanceof etc.. --Daniel5Ko (Diskussion) 14:23, 8. Jun. 2012 (CEST)
Ergänzung: Dass typeof nicht den Typ von Variablen zurückgibt, kann man zum Beispiel in ECMA 262, Ed. 5.1, Punkt 11.4.3 nachlesen. --Daniel5Ko (Diskussion) 15:55, 8. Jun. 2012 (CEST)