NULL

[Bashar]

JustAnotherNoob schrieb:

In anderen OO-Sprachen wie z.B. smalltalk ist "+" nichts Anderes als eine Nachricht (mit einer zweiten Zahl als Parameter), die an Zahlen gesendet wird: 4 + 5 im Sinne von "4.add(5)"

Infixnotation ist praktisch aber wie wird das mit der Operatorenpriorität geregelt?

Gar nicht, das sind wirklich einfach Nachrichten an ein Objekt. 4 + 5 * 3 heißt also: Sende + an 4 und übergib 5, sende * an das Ergebnisobjekt und übergib 3.

[JustAnotherNoob]

Das heißt es kommt bei dieser Operation also als Ergebnis sogar 27 raus?

[+fricky]

JustAnotherNoob schrieb:

so hart wie du denkst, ist der bruch nicht.

Es ist ein Bruch und das ist ausreichend.
Entweder man sagt a oder b, aber so beweist Java doch nur, dass das eigene Konzept schwachsinnig ist.

der bruch ist, dass '+' in den meisten fällen 'ne arithmetische operation, in einem fall ein zusammenkleben von zeichen ist. nun ist aber java.lang.String mit seinem '+' sogar in der sprachdefinition verankert, was das ganze halb so wild macht. wie schon gesagt: kein mensch kann sich selbst einen eigenen +-operator basteln, der irgendwelche seltsamen dinge macht. und das ist das entscheidende.

Dravere schrieb:

Was ist das denn für eine Argumentation? Dir ist schon klar, dass das absolut normale Verhalten von x++ ist, dass vom alten Objekt eine Kopie zurückgegeben wird.

wer sagt das? wenn ich keine kopie brauche, wird auch nix zurückgegeben. aber in C++ ist das vermutlich anders.

Shade Of Mine schrieb:

...denn x++ ist langsamer als ++x (es sei denn der compiler kann das irgendwie optimieren).
Ist in Java und C genauso.

hast du'n beispiel, wo postinkrement in Java (oder C) langsamer ist, als preinkrement?

[JustAnotherNoob]

nun ist aber java.lang.String mit seinem '+' sogar in der sprachdefinition verankert, was das ganze halb so wild macht. wie schon gesagt: kein mensch kann sich selbst einen eigenen +-operator basteln, der irgendwelche seltsamen dinge macht. und das ist das entscheidende.

Nochmal...
entweder es kann sinnvoll sein, oder eben nicht...
ist es manchmal sinnvoll -> Operatorenüberladung
ist es nicht sinnvoll -> Keine Operatorenüberladung

Dass es in Java als Ausnahmefall definiert wird(In der Sprachdefinition verankert ist) macht es nur zu einem Designfehler. Java ist eben das Französisch unter den Programmiersprachen.

wer sagt das? wenn ich keine kopie brauche, wird auch nix zurückgegeben. aber in C++ ist das vermutlich anders.

Nö, C++ Compiler optimieren ebenso, mehr ist das nicht.

[+fricky]

JustAnotherNoob schrieb:

ist es manchmal sinnvoll -> Operatorenüberladung

und genau das ist falsch. 'manchmal' reicht nun mal als grund nicht aus.

[Dravere]

+fricky schrieb:

Dravere schrieb:

Was ist das denn für eine Argumentation? Dir ist schon klar, dass das absolut normale Verhalten von x++ ist, dass vom alten Objekt eine Kopie zurückgegeben wird.

wer sagt das? wenn ich keine kopie brauche, wird auch nix zurückgegeben. aber in C++ ist das vermutlich anders.

Zum Beispiel der C oder der Java Standard. Lies es dort nach!
Dass der Kompiler dies optimieren kann, ist etwas ganz anderes und gehört nicht zur Sprache dazu. Auch ein C++ Kompiler kann sowas optimieren.

Ein vernünftiger Programmierer wird allerdings nicht der Postinkrement aufrufen, damit der Kompiler bei der Optimierung dann ein Preinkrement daraus macht. Wieso nicht gleich ein Preinkrement hinsetzen?

Grüssli

[JustAnotherNoob]

und genau das ist falsch. 'manchmal' reicht nun mal als grund nicht aus.

liest du ab und zu auch was ich schreibe?
Ich meine da waren ganz klar 2 Möglichkeiten..

edit:
und btw. sehe ich das vollkommen anders. Manchmal reicht völlig aus. Weil es eben Momente gibt in denen es sinnvoll ist und es Momente gibt in denen es nicht sinnvoll ist.
Wenn du dir nicht zutraust die Situation richtig einzuschätzen dann kannst dus auch ganz bleiben lassen, selbst dafür musst du dann nicht Java nehmen.

Java Standard

Sowas gibts doch gar nicht?
Die Sprachspezifikation meinst du wohl eher.

[+fricky]

Dravere schrieb:

Ein vernünftiger Programmierer wird allerdings nicht der Postinkrement aufrufen, damit der Kompiler bei der Optimierung dann ein Preinkrement daraus macht. Wieso nicht gleich ein Preinkrement hinsetzen?

x++;     // x lesen, hochzählen, x zuweisen
++x;     // x lesen, hochzählen, x zuweisen
y = x++; // x lesen, y zuweisen, hochzählen, x zuweisen
y = ++x; // x lesen, hochzählen, x zuweisen, y zuweisen

^^wo siehst du da 'nen unterschied? x++ bzw. ++x brauchen jeweils 3 bzw. 4 operationen. wieso sollte ++x schneller sein als x++. unter C++ mag es ja so sein, aber normal ist das nicht.

[Shade Of Mine]

+fricky schrieb:

hast du'n beispiel, wo postinkrement in Java (oder C) langsamer ist, als preinkrement?

Klar.

int i=0;
++i;

Nur weil dein java compiler das optimieren kann heisst es ja nicht dass es meiner können muss.

Die Sache ist halt die, dass es sehr sehr leicht optimierbar ist - keine Frage. Aber die Semantik ist komplett gleich. Ich hab übrigens nen C compiler der das nicht optimieren kann... Wenn für ++x immer x++ verwendet wird, ist das nunmal ein Fehler des programmierers. Kein großer Fehler, aber ein Fehler. Und in gewissen Situationen bestraft C++ nun diesen Fehler. Ich sehe das kein Problem.

und genau das ist falsch. 'manchmal' reicht nun mal als grund nicht aus.

Dir ist schon bewusst dass alle Sprachfeatures nur manchmal gebraucht werden. zB wozu brauch ich for und do while in C? vollkommen unnötig weil redundant.
operatoren überladung fügt dafür ein neues konzept hinzu. ein neues konzept kann definitions bedingt nicht redundant sein.

natürlich können wir jetzt generell allen sprachen alle features wegdiskutieren. wozu zB int, short und long? reicht nicht double für alles?

wozu funktionen wenn wir goto haben...

Ach fricky, bemüh dich doch wenigstens

[JustAnotherNoob]

^^wo siehst du da 'nen unterschied? x++ bzw. ++x brauchen jeweils 3 bzw. 4 operationen. wieso sollte ++x schneller sein als x++. unter C++ mag es ja so sein, aber normal ist das nicht.

Wie kommst du denn darauf?
x++ ist ein Ausdruck der seperat ausgewertet wird(wenn ers nicht wird, optimiert der Compiler).

[Shade Of Mine]

+fricky schrieb:

^^wo siehst du da 'nen unterschied? x++ bzw. ++x brauchen jeweils 3 bzw. 4 operationen. wieso sollte ++x schneller sein als x++. unter C++ mag es ja so sein, aber normal ist das nicht.

doch ist normal, weil keine kopie nötig ist.

natürlich muss ++x nicht schneller sein, aber es kann. eben weil lesen und zuweisen nicht zwangsläufig notwendig sind.

und
++x -> hochzählen
x++ -> zuweisen, hochzählen
plötzlich doch unterschiedlich ist.

[u_ser-l]

JustAnotherNoob schrieb:

Infixnotation ist praktisch aber wie wird das mit der Operatorenpriorität geregelt?

In Smalltalk gibt es keine Operatoren in genau dem Sinne, wie es sie in C++ gibt, sondern nur Nachrichten. Die Prioritätsfolge ist:

Nachrichten ohne Argument (unär)
Nachrichten mit genau einem Argument (binär)
Nachrichten mit Schlüsselwort:/-wörtern:

Außerdem gibt es Klammern zur Manipulation der Auswertungsreihenfolge.

ZB ist in Smalltalk 1 + 2 * 3 gleich 9. Wem das nicht paßt, der muß 1 + (2 * 3) schreiben.

[+fricky]

JustAnotherNoob schrieb:

x++ ist ein Ausdruck der seperat ausgewertet wird(wenn ers nicht wird, optimiert der Compiler).

das gilt für ++x ebenso, wenn der ausdruck ausgewertet wird. wird er's nicht, dann wird eben nur hochgezählt, egal auf welcher seite sich das ++ befindet. bei einem überladenen C++ postinkrement-op würde zuerst eine kopie erzeugt, dann aber weggeworfen werden.

Shade Of Mine schrieb:

und
++x -> hochzählen
x++ -> zuweisen, hochzählen
plötzlich doch unterschiedlich ist.

wo wird da noch was zugewiesen (ausser dem 'x', sein vorheriger wert+1, in beiden fällen)?

[+fricky]

Shade Of Mine schrieb:

Wenn für ++x immer x++ verwendet wird, ist das nunmal ein Fehler des programmierers. Kein großer Fehler, aber ein Fehler. Und in gewissen Situationen bestraft C++ nun diesen Fehler.

es ist ein fehler, der direkt daraus folgt, wie überladene postinkrement-ops in C++ realisiert sind.

[u_ser-l]

auch hier sieht man mal wieder, wie komplizierte Syntax zu eigentlich überflüssigen Einschränkungen in der OOP führen kann.

In einer reinen Objektwelt bedürfte es eigentlich nur Nachrichten an Objekte. Operatoren sind dann Spezialfälle von Nachrichten, und die Polymorphie überladener Operatoren ist nichts Anderes als die einfache Tatsache, daß es erlaubt sein muß, Objekten verschiedener Klassen gleichlautende Nachrichten zu schicken, so, wie das in der realen Welt ganz natürlich ist. Syntax ist doof ...

[JustAnotherNoob]

auf fricky weiter einzugehen erscheint mir hier grad sinnlos, wenn er nicht liest was geschrieben wird soll er halt bei Java bleiben(tut er eh, zumindest steht hier genug, dass eventuelle Mitleser ihn nicht mehr ernst nehmen).

Anderes als die einfache Tatsache, daß es erlaubt sein muß, Objekten verschiedener Klassen gleichlautende Nachrichten zu schicken, so, wie das in der realen Welt ganz natürlich ist. Syntax ist doof ...

Syntax sorgt nur dafür, dass man sich präziser ausdrücken kann, sprich alles kürzer und exakter beschreiben kann. Umschreibungen sind allgemeiner, keine Frage, beides hat Vorteile und Nachteile.
Scala fällt mir grad als Beispiel einer Sprache mit sehr viel Syntax ein, so viele Syntaxregeln erlauben einem auch schon wieder sehr viele Freiheiten.
Wie allgemein eine Syntax sein soll ist aber auch wieder eine andere Frage.

[u_ser-l]

Ich finde eher, Syntax schränkt die Ausdrucksfähigkeiten ein, anstatt sie zu erweitern. Nicht zufällig sind es gerade die Sprachen mit minimaler Syntax, die außergewöhnliche Freiheiten im Ausdruck zulassen (Tcl, Smalltalk, Forth, LISP und wie sie alle heißen).

Scala kenne ich nicht, aber es scheint auf den ersten Blick keine Minimal-Syntax-Sprache zu sein.

[JustAnotherNoob]

Scala kenne ich nicht, aber es scheint auf den ersten Blick keine Minimal-Syntax-Sprache zu sein.

Im Gegenteil

Ich finde eher, Syntax schränkt die Ausdrucksfähigkeiten ein, anstatt sie zu erweitern.

Sag ich ja.
Ich würde sagen eine Sprache mit viel Syntaxregeln ist in den von dem von der Syntax abgedecktem Spektrum kürzer und einfacher zu lesen. Allerdings eben nicht so mächtig. Allerdings: desto mehr zusätzliche Syntaxregeln, desto größer das Spektrum.

[+fricky]

JustAnotherNoob schrieb:

Allerdings: desto mehr zusätzliche Syntaxregeln, desto größer das Spektrum.

nichtsdestotrotz, eine sättigung ist schnell erreicht. es bringt ja nicht viel, wenn du 10 möglichkeiten hat, das gleiche zu tun, aber 8 davon zusätzliche probleme aufwerfen.

[u_ser-l]

JustAnotherNoob schrieb:

Ich würde sagen eine Sprache mit viel Syntaxregeln ist in den von dem von der Syntax abgedecktem Spektrum kürzer und einfacher zu lesen.

Minimalsyntax-Sprachen erlauben es aber ihrerseits, 'domain-specific languages' zu implementieren, die man paßgenau an die Notation der zu lösenden Aufgabe anpassen kann. Z.B. sind in Tcl arithmetische Ausdrücke als Untersprache 'expr' definiert, ohne, daß man dazu den Sprachkern von Tcl mit Syntaxregeln für arithmetische Ausdrücke hätte zukleistern müssen. Genial.

Selbst Objektmodelle lassen sich in Tcl implementieren, ohne die Sprache zu verlassen. Klassenbasierte OO ist zu restriktiv? Kein Problem, man kann ein prototypenbasiertes Objektmodell in Tcl implementieren, ohne zusätzliche Syntaxregeln.