Warum interpretiert langs sind meist ducktyped während kompiliert haben starke Typisierung?

Ich weiß nur nicht, dass es irgendeinen technischen Grund dafür? Ist es schwieriger zu implementieren, einen compiler für eine Sprache mit schwacher Typisierung? Was ist es?

  • Es scheint, Sie sind convoluting einige Begriffe. Python, zum Beispiel, ist eine dynamisch typisierte Sprache mit ducktyping, aber es ist stark typisiert; C hat statischen Typen aber schwach typisiert ist.
  • Ja, ich denke, ich bin dann. Danke für den Tipp, ich werde ich gehen google einige Definitionen und Klärung dieser Begriffe.
InformationsquelleAutor snitko | 2008-12-18
  1. 198

    Die Räumlichkeiten, die hinter der Frage ein bisschen dodgy. Es ist nicht wahr, dass interpretierte Sprachen sind meist ducktyped. Es ist nicht wahr, dass kompilierte Sprachen haben meist starke Typisierung. Die Art system, ist eine Eigenschaft der Sprache. Kompiliert vs. interpretiert ist eine Eigenschaft eines Umsetzung.

    Beispiele:

    • Die Programmiersprache Scheme ist dynamisch typisiert (aka duck-typed), und es hat viele Dutzende interpretiert Implementierungen, aber auch einige feine native-code-Compiler, einschließlich Diebstahl, Gambit, und PLT-Scheme (einschließlich beide einem interpreter und einem JIT-compiler macht nahtlose übergänge).

    • Die Programmiersprache Haskell ist statisch typisiert; die zwei bekanntesten Implementierungen des interpreters HUGS und des Compilers GHC. Es gibt mehrere andere ehrenwerte Implementierungen split gleichmäßig zwischen kompilieren zu systemeigenem code (yhc) und interpretation (Helium).

    • Die Programmiersprache Standard ML ist statisch typisiert, und es hat viele native-code-Compiler, von denen einer der besten und am meisten aktiv gepflegt wird MLton, aber eine der sinnvollsten Implementierungen ist der interpreter Moskau ML

    • Der Programmiersprache Objective Caml ist statisch typisiert. Es kommt mit nur eine Implementierung (von der INRIA in Frankreich), aber diese Implementierung umfasst beide ein Dolmetscher und ein native-code-compiler.

    • Die Programmiersprache Pascal ist statisch typisiert, aber es wurde populär in den 1970er Jahren durch die hervorragende Umsetzung gebaut an der UCSD, die sich auf einer P-code-interpreter. In späteren Jahren feine native-code-Compiler verfügbar war, wie die IBM-Pascal/VS-compiler für die 370-Serie von Computern.

    • Die Programmiersprache C ist statisch typisiert, und heute fast alle Implementierungen kompiliert werden, aber in den 1980er Jahren diejenigen von uns glücklich genug, um mit Säbel-C wurden mit Hilfe eines Dolmetschers.

    Dennoch es gibt eine Wahrheit, die hinter Ihrer Frage, so verdienen Sie eine durchdachte Antwort. Die Wahrheit ist, dass dynamisch typisierte Sprachen zu sein scheinen korreliert mit interpretiert Implementierungen. Warum könnte das sein?

    • Viele neue Sprachen definiert werden, indem eine Implementierung. Es ist einfacher zu bauen ein Dolmetscher als zu build a compiler. Es ist einfacher zu überprüfen dynamische Typen als zu überprüfen Sie statisch. Und wenn Sie schreiben, ein Dolmetscher, es gibt wenig performance-Vorteil der statische Typ-überprüfung.

    • Sofern Sie erstellen oder anpassen, eine sehr flexible polymorphe Typ-system, ein statisches Typsystem ist wahrscheinlich, dass Sie in der programmer ' s Art und Weise. Aber wenn Sie schreiben, ein Dolmetscher, ein Grund könnte sein, erstellen Sie eine kleine, leichte Umsetzung, die bleibt aus der programmer ' s Art und Weise.

    • In einigen interpretierte Sprachen, viele grundlegende Operationen sind so teuer, dass der zusätzliche Aufwand der überprüfung der Typen zur Laufzeit ist egal. Ein gutes Beispiel ist der Nachsatz: "wenn Sie gehen, zu laufen und ab und zu Rastern Bézier-Kurven an der Tropfen einen Hut, man wird sich nicht sträuben bei der überprüfung eines Typ-tag hier oder dort.

    Übrigens, bitte vorsichtig sein, die Begriffe "starke" und "schwache" eingeben, weil Sie nicht haben, eine allgemein vereinbarte technische Bedeutung. Dagegen statische Typisierung bedeutet, dass Programme geprüft, bevor Sie ausgeführt wird, und ein Programm abgelehnt wird, bevor es beginnt. Dynamische Typisierung bedeutet, dass die Werte geprüft während Ausführung, und eine schlecht getippte operation kann das Programm veranlassen, zu stoppen oder anderweitig signal wird ein Fehler zur Laufzeit. Ein Hauptgrund für die statische Typisierung ist, um auszuschließen, Programme, die möglicherweise eine solche "dynamische typfehler". (Dies ist ein weiterer Grund, warum Menschen, die schreiben Dolmetscher sind oft weniger daran interessiert, die statische Typisierung; Ausführung erfolgt sofort nach der überprüfung von Typ, so dass die Unterscheidung und den Charakter der Garantie sind nicht so offensichtlich.)

    Starke Typisierung in der Regel bedeutet, dass es keine Schlupflöcher in das Typ-system, in der Erwägung, dass schwache Typisierung bedeutet das Typ-system kann unterlaufen werden (Aufhebung von Garantien). Die Begriffe werden oft falsch verwendet, um zu bedeuten, statische und dynamische Typisierung.
    Um den Unterschied zu sehen, denke, dass C: die Sprache ist auch Typ-geprüft, zur compile-Zeit (statische Typisierung), aber es gibt viele Schlupflöcher, man kann so ziemlich warf einen Wert beliebigen Typs in einen anderen Typ der gleichen Größe---insbesondere, können Sie cast Zeiger-Typen frei. Pascal war eine Sprache, die gedacht war, stark typisiert, aber bekanntlich hatte eine unvorhergesehene Lücke aufweist: eine Variante aufnehmen, ohne tag.

    Implementierungen von stark typisierten Sprachen oft erwerben, die Lücken im Laufe der Zeit, in der Regel so, dass ein Teil des run-time-system implementiert werden kann, in der high-level-Sprache. Zum Beispiel, Objective Caml hat eine Funktion namens Obj.magic die die run-time-Effekt der Rücksendung argument, aber zur compile-Zeit konvertiert einen Wert beliebigen Typs zu einem anderen Typ. Mein Lieblings-Beispiel ist Modula-3, dessen Designer aufgerufen, Ihre Typ-casting konstruieren LOOPHOLE.

    In der Zusammenfassung:

    • Statische vs dynamische ist die Sprache.

    • Kompiliert vs. interpretiert ist die Umsetzung.

    • Im Prinzip zwei Entscheidungen getroffen werden können und sind orthogonal, aber für sound-technischen Gründen dynamische Typisierung Häufig korreliert mit der interpretation.

    • Sehr informativ, vielen Dank. Aber es gibt noch eine wichtige Frage übrig: zwar Verstand ich die Stolpersteine bei der Umsetzung-interpreter für stark typisierte Sprachen, Sie sagten nichts über die Erhebung von dynamisch typisierten Sprachen.
    • Ich bin kein Experte. Es gibt einen großen Körper der Literatur auf die Zusammenstellung von Scheme und Lisp auf nativen Maschinen-code. Eine Frage stellen und ich werde versuchen Sie zu beantworten 🙂
    • Es ist ein follow-up hier: stackoverflow.com/questions/430182/is-c-strongly-typed#430414
    • Ich hoffe du verzeihst mir meine Fragen. Wenn Dynamische Typisierung bedeutet, dass die Typen der Werte werden bei der Ausführung geprüft, wie kann dann jede interpretierte Sprache ist statisch typisiert?
    • Sie führen ein compiler erzeugt Bytecode, der dann interpretiert wird. Beispiele HIERFÜR sind Objektive Caml, Moskau-ML -, Säbel-C (der fond memory), UCSD-Pascal (der alten lore), und viele andere.
    • also nach dieser Logik, jede interpretierte Sprache, die nicht kompiliert zu bytecode ist dynamisch typisiert, richtig?
    • anscheinend mit dem "neuen" bounty-system (dass er nicht neu), wenn Sie wirklich wollen, um mir +100, Sie können 🙂 blog.stackoverflow.com/2010/06/improvements-to-bounty-system
    • Wirth hatte einen Pascal-Compilers für die CDC-6000 Mitte der 1970-er. Auf Mikro-Computern Pascal Dolmetscher kam vor dem Compiler durch UCSDs sehr beliebt Durchführung, sondern auch auf mainframes und Minis zusammengestellt Pascal war ein Grundnahrungsmittel. Sogar Unix (BSD) hatte eine, Berkeley Pascal.

    InformationsquelleAutor Norman Ramsey
  2. 9

    Dem Grund, dass Sie die frühe Bindung (starke Typisierung) ist die Leistung. Mit der frühen Bindung, finden Sie den Speicherort der Methode zur compile-Zeit, so dass zur Laufzeit Sie bereits weiß, wo Sie lebt.

    Jedoch mit der späten Bindung, die Sie haben zu gehen auf der Suche nach einer Methode, die scheint, wie die Methode, die der client-code aufgerufen. Und natürlich mit vielen, vielen Methodenaufrufen in einem Programm, das ist, was macht dynamische Sprachen "langsam".

    Aber sicher, Sie konnte erstellen eine statisch kompilierte Sprache bedeutet, dass die späte Bindung, die würde negieren viele der Vorteile der statischen Kompilierung.

    • Also, was Sie sagen, kompilierten Sprachen mit später Bindung machen das Programm langsam auf eine Laufzeit? Jetzt wäre es langsamer als Dolmetscher dann?
    • Travis ist zu kurz gedacht. C++ - virtuelle member-Funktionen haben die späte Bindung, sondern ein compiler findet viele nützliche Arbeit zu tun. Die Sprache Selbst hat wirklich späte Bindung, aber Dank Urs Hoelzle ist genial dynamischen compiler, es bekommt sehr gute Leistung. Kein Wunder, dass Urs ist jetzt eine big shot bei Google 🙂
    • Yer, es war ein bisschen ein über Vereinfachung, und ja, es gibt viel Sie tun können, um Geschwindigkeit bis spät gebundene Methode, z.B. lookup caching etc (daher die Anführungszeichen um 'langsam').
    • Frühe/späte Bindung ist unrelevant, zu starke/schwache Typisierung.
    InformationsquelleAutor tsimon
  3. 4

    Es ist ziemlich viel, weil Leute, die schreiben, und verwenden Sie interpretierten Sprachen bevorzugen ducktyping, und denjenigen, die Sie entwickeln und verwenden kompilierte Sprachen bevorzugen starke explizite Eingabe. (Ich denke, der Konsens Grund dafür wäre irgendwo im Bereich von 90% zur Fehlervermeidung, und 10% für die Leistung.) Für die meisten Programme die heute geschrieben wird, ist die Geschwindigkeit Unterschied unwesentlich sein sollten. Microsoft Word hat laufen lassen auf p-code (nicht kompilierte) für - was - 15 Jahren?

    Besten Fall in Punkt, den ich denken kann. Klassischen Visual Basic (VB6/VBA/etc.) Das gleiche Programm könnte sein, geschrieben in VB und lassen sich mit identischen Ergebnissen und vergleichbaren Geschwindigkeit entweder kompiliert oder interpretiert werden. Darüber hinaus haben Sie die Möglichkeit, Typ-Deklarationen (in der Tat Variablendeklarationen) oder nicht. Die meisten Menschen bevorzugte Art von Erklärungen, in der Regel zur Fehlervermeidung. Ich habe noch nie gehört oder gelesen, überall zu verwenden, geben Erklärungen für die Geschwindigkeit. Und dies geht zurück mindestens so weit wie zwei Mächte von der Größe in hardware-Geschwindigkeit und Kapazität.

    Google ist immer eine Menge Aufmerksamkeit in letzter Zeit aufgrund Ihrer Arbeit auf einen JIT-compiler für javascript erfordern keine änderungen an der Sprache, oder erfordern eine Besondere Berücksichtigung seitens der Programmierer. In diesem Fall, der einzige Vorteil wird sein speed.

    InformationsquelleAutor dkretz
  4. 3

    Da Programmiersprachen, die kompiliert werden müssen, um die Menge des verwendeten Speichers in Konto, wenn Sie kompiliert werden.

    Wenn Sie etwas sehen wie:

    int a

    in C++ der compiler spuckt code, behält sich die vier bytes des Speichers und weist das lokale symbol "a" zu Punkt, dass der Speicher. Wenn Sie hatte eine typeless scripting-Sprache wie javascript, die Dolmetscher, die hinter den kulissen ordnet den erforderlichen Speicher. Sie tun kann:

    var a = 10;  //a is probably a four byte int here
a = "hello world"; //now a is a 12 byte char array

    Es ist viel passiert zwischen diesen beiden Linien. Der Dolmetscher löscht den Speicher, weist der neue Puffer für die chars, dann weist der eine var zu zeigen, dass die neuen Speicher. In einer stark typisierten Sprache, es gibt keine Dolmetscher, die es schafft, dass für Sie und so muss der compiler schreiben Sie Anweisungen, die in Betracht Art.

    int a = 10; //we now have four bytes on the stack.
a = "hello world"; //wtf? we cant push 12 bytes into a four byte variable! Throw an error!

    Damit der Compiler hält, dass code aus kompilieren, damit die CPU somit nicht blind schreiben 12 bytes in vier byte-Puffer und verursachen Elend.

    Den zusätzlichen Aufwand für einen compiler schreiben zusätzliche Anweisungen zum aufpassen geben würde verlangsamen die Sprache deutlich, und entfernen Sie den nutzen von Sprachen wie C++.

    🙂

    -nelson

    EDIT in Antwort zu Kommentar

    Ich weiß nicht viel über Python, daher kann ich darüber nicht so viel sagen. Aber Locker typedness verlangsamt sich die Laufzeit erheblich. Jede Anweisung, die dem interpreter (VM) fordert, hat zu evaulate, und wenn nötig, zu zwingen, die var in den erwarteten Typ. Wenn Sie haben:

    mov a, 10
mov b, "34"
div a, b

    Dann der Dolmetscher ist darauf zu achten, dass eine variable ist, und eine Zahl, dann müsste es zu zwingen, b in einer Reihe vor der Verarbeitung der Anweisung. Hinzufügen, dass der Aufwand für jede Anweisung, dass der VM ausgeführt wird und Sie haben ein Chaos auf Ihre Hände 🙂

    • Es gibt keinen Grund, warum diese Art der Speicherverwaltung konnte nicht in einer VM wie Java oder .NET, aber es ist nicht, weil es gibt andere Vorteile der starken Typisierung.
    • Sie nicht aufgrund von Leistung. Eine bessere Frage ist "warum wollen Sie eine lose typisierte Sprache?" Rufen Sie mich altmodisch oder elitär, aber ich fühle mich nicht wohl dabei, meine Variablen " - Typen sind nicht erzwungen, indem der interpreter.
    • Oh, und die CLR ist nicht wirklich eine VM, weil es JITs die IL in Maschinensprache, bevor es läuft.
    • Ich habe geschrieben eine Menge von perl, und eine Menge von C/C++/Java. Beide haben Ihren nutzen. Ich würde nicht schreiben wollen, ein Lohn-system in eine lose typisierte Sprache, aber ich will auch nicht zu haben, um zu definieren, - Schnittstellen und-Klassen für meinen Datei-parser.
    • Könnten Sie bitte klären: was bedeutet "slow down die Sprache'? Ist es eine Verlangsamung bei der Kompilierung-Zeit oder zur Laufzeit? Und, soweit ich weiß, Python ist ein compiler. Was ist Los mit ihm dann?
    InformationsquelleAutor
  5. 2

    Ich vermute, dass Sprachen mit dynamischen (Ente) - Typisierung beschäftigen lazy evaluation, die-begünstigt durch faule Programmierer, und faule Programmierer nicht gerne schreiben-Compiler 😉

    • drive-by-downvoters haben keinen Sinn für humor. zum Glück, ich weiß es.
    • Wenn Sie schon über 10k (oder fast, dass in meinem Fall) Ruf, es ist nicht zu schmerzhaft ist Sie zu opfern einer oder zwei für einen Witz, oder?
    • Ein Programmierer beste Eigenschaft ist, dass er/Sie faul ist!
    • Ich Schätze den Witz, aber wie wollen Sie damit umgehen, dass dieser immer größer, als eine echte Antwort? Vielleicht, wie ich zu tun: Lesen Sie weiter, alle nicht-negativen Ruf Antworten 🙂
    • Ich Griff Sie lachend. Eine lustige Antwort - mit einem Körnchen Wahrheitsgehalt! - nicht verhindern, dass nicht-lustige Antworten angezeigt wird und/oder darüber abgestimmt wird bis.
    • Heh, es ist ein nettes Wortspiel, aber was ist die Wahrheit? Die meisten Sprachen mit dynamischen (Ente) Eingabe von nicht tun, lazy evaluation (standardmäßig), und der lazy evaluation ist berühmt in Haskell, die hat ein statisches Typsystem und eine ausgezeichnete compiler. 🙂
    • ich bin verwirrt, ich glaube nicht, dass es möglich ist, zu tun, duck typing, ohne lazy evaluation (späte Bindung/dynamische Bindung)...
    • Ente Eingabe von ist im Zusammenhang mit late binding, aber der lazy evaluation ist etwas ganz anderes: en.wikipedia.org/wiki/Lazy_evaluation ist.gd/bZbT usw, denke bei Unix-pipes: ist.gd/dAtP (und natürlich das geniale "Warum FP" - Papier ist.gd/dAtY, die wirklich über lazy evaluation)
    • nicht streiten, über einen Witz zu posten, aber "call-by-name und lazy evaluation sind jeweils eine form der späten Bindung" -- academic.udayton.edu/SaverioPerugini/courses/cps343/... 😉
    • Das ist interessant, danke. 🙂 Hatte nicht gedacht lazy evaluation (oder call-by-name) als eine form des "late binding". (In jedem Fall aber das Gegenteil ist nicht wahr, nicht jeder, der die späte Bindung ist lazy evaluation, und die meisten dynamisch typisierte Sprachen haben keine lazy evaluation...) Es ist alles nur Worte, am Ende. 🙂
    • IMO lazy evaluation hat wenig zu tun mit der späten Bindung: lazy evaluation bedeutet, dass Sie reduzieren einen Ausdruck, wenn der Wert erforderlich ist, wird die späte Bindung bezeichnet, wenn Sie binden einen Namen zu einem Ausdruck. In Haskell, beispielsweise, wenn Sie schreiben x = 12 + y, x ist unmittelbar gebunden an eine gedacht, aber der thunk ausgewertet wird verzögert (später). Das ist zumindest meine intuition, wie lazy evaluation arbeitet in Haskell.

    InformationsquelleAutor Steven A. Lowe
  6. 2

    Gibt es im wesentlichen zwei Gründe für die Verwendung der statischen Typisierung wird über duck typing:

    1. Statische Fehler überprüfen.
    2. Leistung

    Wenn Sie eine interpretierte Sprache ist, dann gibt es keinen compile-Zeit, die für die statische Fehlerprüfung stattfinden. Es geht einen Vorteil. Außerdem, wenn du schon den Aufwand für den interpreter, dann ist die Sprache schon nicht für alles verwendet werden performance-kritische, also das performance-argument hinfällig. Dies erklärt, warum die statisch typisierte, interpretierte Sprachen sind selten.

    Gehen den anderen Weg, duck typing kann emuliert werden, zu einem großen Teil in statisch typisierten Sprachen, ohne völlig aufzugeben, die Vorteile der statischen Typisierung. Dieses erfolgt über eine der folgenden Optionen:

    1. Vorlagen. In diesem Fall, wenn der Typ, den Sie instanziieren der Schablone mit unterstützt alle Methoden aufgerufen, die innerhalb der template-code, kompiliert und funktioniert. Ansonsten gibt es einen compile-Zeit-Fehler. Das ist ein bisschen wie compile-Zeit-duck-typing.
    2. Reflexion. Sie versuchen, eine Methode aufzurufen, die mit Namen, und entweder es funktioniert, oder wirft eine exception.
    3. Getaggt Gewerkschaften. Dies sind im wesentlichen container-Klassen für andere Arten enthalten einige Speicherplatz und ein Feld beschreibt die Art aktuell enthalten. Diese werden verwendet, für Dinge wie algebraische Typen. Wenn eine Methode aufgerufen wird, wird es entweder funktioniert oder wirft, je nachdem, ob die Art gegenwärtig enthalten die es unterstützt.

    Dies erklärt, warum es wenige sind, die dynamisch typisierten, kompilierten Sprachen.

    • "Wenn man eine interpretierte Sprache ist, dann gibt es keinen compile-Zeit, die für die statische Fehlerprüfung stattfinden." Diese falsche. Sie können check-Typen zur Analysezeit.
    InformationsquelleAutor dsimcha
  7. 1

    Sprachen mit schwacher Typisierung kompiliert werden kann, zum Beispiel, Perl5, und die meisten Versionen von Lisp sind kompilierte Sprachen. Die performance-Vorteile zu kompilieren, sind oft verloren, weil viel von der Arbeit, die Sprache, die Laufzeit zu erbringen hat, ist zu tun mit der Bestimmung, welche Art eine dynamische variable wirklich hat zu einem bestimmten Zeitpunkt.

    Nehmen Sie zum Beispiel folgenden code in Perl:

    $x=1;
$x="hello";
print $x;

    Ist es natürlich ziemlich schwierig für den compiler, um zu bestimmen, welche Art $x hat wirklich an einem bestimmten Punkt in der Zeit. In der Zeit der print-Anweisung, die Arbeit muss getan werden, um das herauszufinden. In einer statisch typisierten Sprache, die Art ist vollständig bekannt, so dass die performance zur Laufzeit erhöht werden kann.

    • Compiler sind perfekt in der Lage code zu beschäftigen, mit was auch immer Typen zeigen sich bei der Ausführung Zeit. Visual Basic 6 ist eine sehr beliebte kompilierbare Sprache, für die keine Typ-Deklarationen - aber Sie können Sie verwenden, wenn Sie möchten.
    • VB6 Variablen, die nicht angegeben sind, werden implizit typisiert als Varianten. Diese sind in etwa Analog zu einem skalaren Typ in Perl und braucht dieselbe Art von hinter den kulissen tragen, dass alle anderen dynamisch typisierte Sprachen haben
    InformationsquelleAutor 1800 INFORMATION
  8. 0

    Eine Vermutung:

    In einer kompilierten Sprache, ein system (der compiler) zu sehen bekommt, sind alle code erforderlich, um starke Typisierung. Dolmetscher in der Regel nur ein klein wenig das Programm zu einer Zeit, und so kann das nicht tun, die Art von cross-Prüfung.

    Aber dies ist nicht eine harte und schnelle Regel - es wäre durchaus möglich, eine stark typisierte, interpretierte Sprache, aber das würde gegen die Art von "lose" Allgemeinen fühlen Sie sich von interpretierten Sprachen.

    • Die Frage ist, warum sollte Sie das tun? So, dass die Menschen das schreiben von C++ nicht haben, um zu verstehen, weniger über das, was Ihr code eigentlich Dosis an den computer und schreiben eine Reihe von ineffizienten code?
    • Da einige Programmierer wie die Freiheit der späten Bindung. Andere, wie der Komfort der compiler die Durchsetzung von Disziplin. Ich mag beide in Ihren Platz.
    • Auch im Locker-Typen Sprachen es wird gemeinhin als "schlechte Praxis" um die gleiche, var für mehrere Typen zur Laufzeit oder schreiben Sie eine Funktion/Methode, die zurückgibt, Variablen unterschiedlichen Typs. Warum also ist es eine gute Sache?
    • Eine Sache ich mag über perl ist, dass ich kann, wertet einen string aus einer Datei, und wenn es wie eine Zahl aussieht, verwenden Sie es als eine Zahl ohne Konvertierung. Viel schneller schreiben als Integer.parseInt/NumberFormatException fangen.
    • Alle großen, bis man ein schlecht gebildet-Datei und das Programm gerne verwendet null überall.
    • Deshalb benutze ich perl für einige Dinge, und Java für andere.

    InformationsquelleAutor Paul Tomblin
  9. 0

    Einige Sprachen gemeint sind, laufen perfekt in außergewöhnlichen Bedingungen und geopfert werden für schreckliche Leistung, die Sie laufen in während der außergewöhnlichen Bedingungen, daher sehr starke Typisierung. Andere waren nur gedacht, um das Gleichgewicht mit zusätzlichen Verarbeitung.

    Mal, es gibt noch mehr im Spiel als nur die Eingabe. Nehmen Sie ActionScript zum Beispiel. 3.0 eingeführt stärker eingeben, aber dann wieder ECMAScript-ermöglicht Ihnen das ändern von Klassen, wie Sie sehen, passen, zur Laufzeit und ActionScript hat die Unterstützung für dynamische Klassen. Sehr ordentlich, aber die Tatsache, Sie sind die besagt, dass dynamische Klassen sollten nicht verwendet werden, die in "standard" - builds bedeutet, es ist ein no-no, wenn Sie brauchen, um es zu spielen safe.

    InformationsquelleAutor Filip Dupanović
Schreibe einen Kommentar