Das deutsche Python-Forum

@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".

BlackJack hat geschrieben: In C, Java, C#, usw. jedenfalls nicht --

Nun das sind alles statisch typisierende Sprachen, wo es natürlich keine "Defaultdeklaration" ohne Keyword geben kann!

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)

grummel...

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...

@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.

@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.

@LanX: Ich kritisiere das nicht aus meinem "Py-POV".

BlackJack hat geschrieben:@LanX: Ich kritisiere das nicht aus meinem "Py-POV".

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.

LanX hat geschrieben:
BlackJack hat geschrieben: In C, Java, C#, usw. jedenfalls nicht --
Nun das sind alles statisch typisierende Sprachen, wo es natürlich keine "Defaultdeklaration" ohne Keyword geben kann!

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:Ja, aber in diesen, und den meisten anderen Sprachen brauchst du einen Deklarationsbefehl damit es lokal ist.

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.

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???

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.

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.

Schön wieder etwas gelernt ...

Aber gehe ich recht in der Annahme dass ``val`` oder ``var`` in diesen Sprachen einen lokalen Scope erwirken?

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.

Gut ich habe deinen Standpunkt verstanden, es ist nicht zu akzeptieren das JS sich hier am Mainstream orientiert ...

... zum Glück liegt die Lösung nicht fern

Viel Glück!

LanX hat geschrieben:
Darii hat geschrieben:Gut ich habe deinen Standpunkt verstanden, es ist nicht zu akzeptieren das JS sich hier am Mainstream orientiert ...

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…

Edit: Gegenbeispiel vom „Mainstream“: PHP macht es genauso wie Python und Ruby…

LanX hat geschrieben:Aber gehe ich recht in der Annahme dass ``val`` oder ``var`` in diesen Sprachen einen lokalen Scope erwirken?

Ganz recht, beide Keywörter erwirken einen lokalen Scope.

Darii hat geschrieben:Edit: Gegenbeispiel vom „Mainstream“: PHP macht es genauso wie Python und Ruby…

Ah stimmt, jetzt sind es drei. Danke!

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 ..

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.

Also, meine Aussage war dass das JS einen sehr flexiblen Kern bildet mit dem beliebig komplexe Pattern abgebildet werden können.

Die Tatsache dass so viele XYZ to JS Projekte (XYZ=Python hab ich bereits gelistet) spricht m.E. für diese These.

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.

Spätestens an dieser Stelle möchte ich mal freundlich Autsch zu dir sagen.

snafu hat geschrieben:Spätestens an dieser Stelle möchte ich mal freundlich Autsch zu dir sagen.

Dem möchte ich ein freundliches Ups erwidern!

LanX hat geschrieben:Ah stimmt, jetzt sind es drei. Danke!

Soll ich jetzt Erbsen zählen? Ab wieviel Sprachen ist es genug Mainstream dass ich deswegen JS kritisieren darf?

Du hast bis jetzt BASIC und Perl angeboten. Ich lege gnädiger Weise nochmal Lua drauf, also haben wir bis jetzt Gleichstand.

Also, meine Aussage war dass das JS einen sehr flexiblen Kern bildet mit dem beliebig komplexe Pattern abgebildet werden können.

Hat ja niemand bestritten. Kann man aber mit jeder anderen Turing-vollständigen Sprache auch machen.

Die Tatsache dass so viele XYZ to JS Projekte (XYZ=Python hab ich bereits gelistet) spricht m.E. für diese These.

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.

Darii hat geschrieben:Zitat:
Lanx hat geschrieben:Also, meine Aussage war dass das JS einen sehr flexiblen Kern bildet mit dem beliebig komplexe Pattern abgebildet werden können.
Hat ja niemand bestritten. Kann man aber mit jeder anderen Turing-vollständigen Sprache auch machen.

doch leider ich

Soweit ich das im Kopf habe ist JS klassenlos.

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

Nach meiner Auffassung brauche ich für die meisten Patterns jedoch Klassen.
z.B. Visitor, Factory, Proxy - Pattern.

[ironie]Aber wahrscheinlich kann man die ohnehin ohne Klassen viel schöner abbilden [/ironie]

Grüße

rads hat geschrieben:Soweit ich das im Kopf habe ist JS klassenlos.

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.

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?

Nach meiner Auffassung brauche ich für die meisten Patterns jedoch Klassen.
z.B. Visitor, Factory, Proxy - Pattern.

Nein. Braucht man nicht. Klassen sind einfach nur ein (zugegebener Maßen oft sinnvolles) Strukturierungselement, kein Selbstzweck.

rads hat geschrieben:
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
Nach meiner Auffassung brauche ich für die meisten Patterns jedoch Klassen.
z.B. Visitor, Factory, Proxy - Pattern.

[ironie]Aber wahrscheinlich kann man die ohnehin ohne Klassen viel schöner abbilden [/ironie]

Grüße

Die Terminologie Klassenlos bzw. classless bezieht sich auf die prototypische Vererbung die kein explizites Klassenpattern als Sprachkonstrukt hat. (JS2 will das einführen)

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

Darii hat geschrieben:
Also, meine Aussage war dass das JS einen sehr flexiblen Kern bildet mit dem beliebig komplexe Pattern abgebildet werden können.
Hat ja niemand bestritten. Kann man aber mit jeder anderen Turing-vollständigen Sprache auch machen.

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.

(Zugegeben mit FORTH kenne ich mich nicht aus, ob das auch ginge weiß ich nicht)

Das deutsche Python-Forum

Python to C Converter

Re: Python to C Converter

Re: Python to C Converter

Re: Python to C Converter

Re: Python to C Converter

Re: Python to C Converter

Re: Python to C Converter

Re: Python to C Converter

Re: Python to C Converter

Re: Python to C Converter

Re: Python to C Converter

Re: Python to C Converter

Re: Python to C Converter

Re: Python to C Converter

Re: Python to C Converter

Re: Python to C Converter

Re: Python to C Converter

Re: Python to C Converter

Re: Python to C Converter

Re: Python to C Converter

Re: Python to C Converter