Python to C Converter
@LanX: Der Punkt beim ``var`` begegnet einem nicht überall. Bei welchen Sprachen kann man denn so einfach aus versehen den globalen Namensraum vollmüllen? In C, Java, C#, usw. jedenfalls nicht -- da muss man die Variable auch irgendwo da draussen noch einmal explizit deklarieren, sonst kompiliert es gar nicht erst. Man muss bei JavaScript also immer an das ``var`` denken, denn das ist ja das was man in 99% der Fälle haben will, aber es ist nicht so offensichtlich wenn man es mal vergisst. Weil das trotzdem noch "funktioniert".
Nun das sind alles statisch typisierende Sprachen, wo es natürlich keine "Defaultdeklaration" ohne Keyword geben kann!BlackJack hat geschrieben: In C, Java, C#, usw. jedenfalls nicht --
Was ich meinte ist dass "var" den gleichen Scope erzwingt wie "int".
Ich kenne es schon traditionell von BASIC, das es einen "local"-Befehl gibt, das spiegelt sich auch in den meisten mir bekannten Scriptsprachen wieder. (in Perl steht "my" analog zu "var"¹ für lexikalische Variablen)
Bereits LISP muss man explizit mit "let" lokalisieren, während "set" global ist.
Ergo ist das Verhalten von Python und Ruby² IMHO nicht die Regel.
Dafür das man nicht versehentlich einen globale Variable deklariert kann man üblicherweise eine explizite Deklaration erzwingen (in Perl mit "use strict;")³
Ich denke jslint kann für solche "strictness" in JS benutzt werden.
Darüber welches Verhalten (local vs nonlocal) nun mehr Vorteile hat, will ich mir jetzt kein Urteil anmaßen...
Worauf ich hinaus wollte, dass JS sich so verhält wie die meisten anderen Scriptsprachen, kann man wohl kaum als spezifische Kritik an JS anführen...
1) allerdings global ist bei mir var nicht lexikalisch!
Code: Alles auswählen
javascript: var a=10; alert(window.a)
NACHTRAG:
2) in Ruby ist es tatsächlich nochmal etwas anders, dort gibts einen expliziten Sigil für global vars
http://www.rubyist.net/~slagell/ruby/globalvars.html
3) interessant, ECMA-Script 5 führt auch "use strict" ein...
Zuletzt geändert von LanX am Sonntag 25. Juli 2010, 18:30, insgesamt 2-mal geändert.
@LanX: Wieso kann man das nicht als Kritik an JavaScript anführen? Nur weil Perl genau so dämlich an der Stelle ist, wird's bei JavaScript ja nicht besser. Im Gegenteil -- JavaScript ist wesentlich jünger, da hätte man ja aus den Fehlern lernen können.
BASIC anzuführen ist an der Stelle ein wenig problematisch, weil es das so nicht gibt. Das original BASIC hatte keine Funktionen/Sichtbarkeitsbereiche und in Dialekten wird es wahrscheinlich alle möglichen Semantiken geben.
BASIC anzuführen ist an der Stelle ein wenig problematisch, weil es das so nicht gibt. Das original BASIC hatte keine Funktionen/Sichtbarkeitsbereiche und in Dialekten wird es wahrscheinlich alle möglichen Semantiken geben.
@BlackJack:
ich sagte "spezifische" Kritik an JS!¹
Du kannst natürlich von deinem Py-POV generell alle anderen Sprachen dafür kritisieren, das sie nicht per default lokalisieren (Aber auch diesbzgl war ich deutlich)
NACHTRAG:
1)vielleicht wäre die Wortwahl "JS-spezifische Kritik" deutlicher gewesen.
ich sagte "spezifische" Kritik an JS!¹
Du kannst natürlich von deinem Py-POV generell alle anderen Sprachen dafür kritisieren, das sie nicht per default lokalisieren (Aber auch diesbzgl war ich deutlich)
NACHTRAG:
1)vielleicht wäre die Wortwahl "JS-spezifische Kritik" deutlicher gewesen.
Bei einem NPOV stellt sich dann die Frage wieso du eine sachlich Diskussion mit Wörtern wie "dämlich" emotionalisierst und den Flame-faktor anhebst.BlackJack hat geschrieben:@LanX: Ich kritisiere das nicht aus meinem "Py-POV".
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Huch? "Natürlich" würde das gehen, denn für statisch typisierte Sprachen gibt es durchaus Type Inference und C# und Scala machen das in einem bestimmten Umfang ja auch. Das sie trotzdem Keywords wie ``val`` oder ``var`` nutzen ist IMHO eher eine Syntaxentscheidung aber nicht zwingend notwendig, weil der Typ ja auch so bestimmt werden kann.LanX hat geschrieben:Nun das sind alles statisch typisierende Sprachen, wo es natürlich keine "Defaultdeklaration" ohne Keyword geben kann!BlackJack hat geschrieben: In C, Java, C#, usw. jedenfalls nicht --
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Nein, da brauche einen Deklarationsbefehl damit das überhaupt eine Variable ist. Und selbst wenn das tausend andere Sprachen auch so machen ist das noch lange keine Entschuldigung, dass das in den meisten Fällen gewünschte Verhalten umständlicher zu verwirklichen ist als das ungewünschte Verhalten.LanX hat geschrieben:Ja, aber in diesen, und den meisten anderen Sprachen brauchst du einen Deklarationsbefehl damit es lokal ist.
ka da jetzt und auch in den nächsten Jahren sowieso kein Py3 benutzen werde ist mir nonlocal auch relativ egal. Die seltenen Fälle in denen man es braucht, kann man auch mit Listen oder Dummy-Objekten abdecken. Gefunden werden sie ja so oder so.1) wobei ich jetzt nicht glaube das "nonlocal" in Py selbst eine Deklaration ist, die Variable muss bereits in einem äußeren Scope deklariert worden sein, oder wird damit implizit eine globale Variable deklariert???
Schön wieder etwas gelernt ...Leonidas hat geschrieben: Huch? "Natürlich" würde das gehen, denn für statisch typisierte Sprachen gibt es durchaus Type Inference und C# und Scala machen das in einem bestimmten Umfang ja auch. Das sie trotzdem Keywords wie ``val`` oder ``var`` nutzen ist IMHO eher eine Syntaxentscheidung aber nicht zwingend notwendig, weil der Typ ja auch so bestimmt werden kann.
Aber gehe ich recht in der Annahme dass ``val`` oder ``var`` in diesen Sprachen einen lokalen Scope erwirken?
Gut ich habe deinen Standpunkt verstanden, es ist nicht zu akzeptieren das JS sich hier am Mainstream orientiert ...Darii hat geschrieben: Und selbst wenn das tausend andere Sprachen auch so machen ist das noch lange keine Entschuldigung, dass das in den meisten Fällen gewünschte Verhalten umständlicher zu verwirklichen ist als das ungewünschte Verhalten.
... zum Glück liegt die Lösung nicht fern
Viel Glück!
Welcher Mainstream? Das ist nur bei einigen Scriptsprachen der Fall. Da ist das auch sinnvoll. Aber JS wird ja von allen Ecken und Enden zur Sprache für ernsthafte Anwendungsentwicklung vorgeschlagen, da ist das nicht mehr schlau. Aber das ist ja nicht mein einziges Problem mit JS…LanX hat geschrieben:Darii hat geschrieben:Gut ich habe deinen Standpunkt verstanden, es ist nicht zu akzeptieren das JS sich hier am Mainstream orientiert ...
Edit: Gegenbeispiel vom „Mainstream“: PHP macht es genauso wie Python und Ruby…
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Ganz recht, beide Keywörter erwirken einen lokalen Scope.LanX hat geschrieben:Aber gehe ich recht in der Annahme dass ``val`` oder ``var`` in diesen Sprachen einen lokalen Scope erwirken?
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Ah stimmt, jetzt sind es drei. Danke!Darii hat geschrieben:Edit: Gegenbeispiel vom „Mainstream“: PHP macht es genauso wie Python und Ruby…
Allerdings wird PHP wohl seinem Ruf gerecht es im Detail grausam zu verkorksen...
http://php.net/manual/de/language.variables.scope.php
mit "global" kann man nur auf den Toplevelscope zugreifen, sprich "richtige" Closures sind nicht oder nur bedingt möglich.
Nochmal für die Akten, ich habe nix gegen per default-lokalisieren ..
Also, meine Aussage war dass das JS einen sehr flexiblen Kern bildet mit dem beliebig komplexe Pattern abgebildet werden können.Darii hat geschrieben: Aber JS wird ja von allen Ecken und Enden zur Sprache für ernsthafte Anwendungsentwicklung vorgeschlagen, da ist das nicht mehr schlau.
Die Tatsache dass so viele XYZ to JS Projekte (XYZ=Python hab ich bereits gelistet) spricht m.E. für diese These.
Spätestens an dieser Stelle möchte ich mal freundlich Autsch zu dir sagen.LanX hat geschrieben:Die Tatsache dass so viele XYZ to JS Projekte (XYZ=Python hab ich bereits gelistet) spricht m.E. für diese These.
Soll ich jetzt Erbsen zählen? Ab wieviel Sprachen ist es genug Mainstream dass ich deswegen JS kritisieren darf?LanX hat geschrieben:Ah stimmt, jetzt sind es drei. Danke!
Du hast bis jetzt BASIC und Perl angeboten. Ich lege gnädiger Weise nochmal Lua drauf, also haben wir bis jetzt Gleichstand.
Hat ja niemand bestritten. Kann man aber mit jeder anderen Turing-vollständigen Sprache auch machen.Also, meine Aussage war dass das JS einen sehr flexiblen Kern bildet mit dem beliebig komplexe Pattern abgebildet werden können.
M.E. spricht das maximal dafür, dass JS nicht so toll ist und man das deswegen nicht anfassen möchte. Der eigentliche Grund wird aber sein, dass man seine Anwendung nicht in mehreren Sprachen entwickeln möchte etc., siehe auch GWT.Die Tatsache dass so viele XYZ to JS Projekte (XYZ=Python hab ich bereits gelistet) spricht m.E. für diese These.
doch leider ichDarii hat geschrieben:Zitat:Hat ja niemand bestritten. Kann man aber mit jeder anderen Turing-vollständigen Sprache auch machen.Lanx hat geschrieben:Also, meine Aussage war dass das JS einen sehr flexiblen Kern bildet mit dem beliebig komplexe Pattern abgebildet werden können.
Soweit ich das im Kopf habe ist JS klassenlos.
Nach meiner Auffassung brauche ich für die meisten Patterns jedoch Klassen.http://de.wikipedia.org/wiki/JavaScript hat geschrieben:Der als ECMAScript (ECMA 262) standardisierte Sprachkern von JavaScript beschreibt eine moderne, schlanke, dynamisch typisierte, objektorientierte, aber klassenlose Skriptsprache
z.B. Visitor, Factory, Proxy - Pattern.
[ironie]Aber wahrscheinlich kann man die ohnehin ohne Klassen viel schöner abbilden [/ironie]
Grüße
Dafür hat Javascript Prototypen. Damit lassen sich Klassen trivial abbilden. Klassen sind bei prototyp-basierten Sprache nur ein Name für eine spezielle Gruppe von Objekten (sofern man das Wort Klasse überhaupt benutzt). Nämlich eben solchen, die als Vorlage für weitere Objekte dienen. Und genau das sind Klassen. Vorlagen.rads hat geschrieben:Soweit ich das im Kopf habe ist JS klassenlos.
Siehe auch den angehänger Screenshot von Self:
Uploaded with ImageShack.us
Oben ist die „Klasse“ dictionary zu erkennen, unten die durch Senden einer copy-Nachricht erzeugte Kopie(„Instanz“) von „dictionary“. Das Verhalten erhalten beide über das gemeinsame trait dictionary (durch die Verbindungslinien zu erkennen). Auch wenn man jetzt über die genaue Definition der Begriffe streiten kann, sieht doch irgendwie sehr nach Klassen und Instanzen aus oder?
Nein. Braucht man nicht. Klassen sind einfach nur ein (zugegebener Maßen oft sinnvolles) Strukturierungselement, kein Selbstzweck.Nach meiner Auffassung brauche ich für die meisten Patterns jedoch Klassen.
z.B. Visitor, Factory, Proxy - Pattern.
Zuletzt geändert von Darii am Montag 26. Juli 2010, 13:20, insgesamt 1-mal geändert.
Die Terminologie Klassenlos bzw. classless bezieht sich auf die prototypische Vererbung die kein explizites Klassenpattern als Sprachkonstrukt hat. (JS2 will das einführen)rads hat geschrieben:Nach meiner Auffassung brauche ich für die meisten Patterns jedoch Klassen.http://de.wikipedia.org/wiki/JavaScript hat geschrieben:Der als ECMAScript (ECMA 262) standardisierte Sprachkern von JavaScript beschreibt eine moderne, schlanke, dynamisch typisierte, objektorientierte, aber klassenlose Skriptsprache
z.B. Visitor, Factory, Proxy - Pattern.
[ironie]Aber wahrscheinlich kann man die ohnehin ohne Klassen viel schöner abbilden [/ironie]
Grüße
Man hat aber sehr wohl "Konstruktoren", mit denen Instanzobjekte generiert werden. Und diese Instanzen gehören dann einer Menge (oder richtigerweise Klasse) abgeleiteter Objekte an. (Sprachlich ist das leider verwirrend, auch weil noch eine dritte Bedeutung von "klassisch", im Sinne von traditionell in den Texten vorkommt)
Deine erwähnten Java-OOP-Pattern der klassischen Klassenbasierte Vererbung (ich sprach nicht nur von OOP Mustern) zur Erzeugung von Instanzklassen lassen sich aber ziemlich problemlos in JS simulieren, wenn man zusätzlich Closures nutzt.
Diesbzgl. Link wird gleich nachgereicht.
et voila!
http://www.crockford.com/javascript/inheritance.html
Zuletzt geändert von LanX am Montag 26. Juli 2010, 13:15, insgesamt 1-mal geändert.
Ich denke es ist ein Unterschied ob man eine andere Sprache mit geringer Performance emuliert - wie das Turing-vollständigen Sprachen können - oder nahe am Sprachkern abbilden kann ohne zuviele Abstraktionslayer drüberlegen zu müssen.Darii hat geschrieben:Hat ja niemand bestritten. Kann man aber mit jeder anderen Turing-vollständigen Sprache auch machen.Also, meine Aussage war dass das JS einen sehr flexiblen Kern bildet mit dem beliebig komplexe Pattern abgebildet werden können.
(Zugegeben mit FORTH kenne ich mich nicht aus, ob das auch ginge weiß ich nicht)