Methoden mit bool-Parametern und "Lesbarkeit" im Kontext

[Apollon]

chrische5 schrieb:

Xin macht den gleichen Fehler, den er den Großen der Zunft vorwirft. es ist beratungsresistent. Er gibt es aber nicht zu. Ere tarnt es einfach dadurch, dass er anderen Unkenntnis unterstellt oder ihnen vorwirft im Kindergarten zu sein.

Xin hat dem Ratze die Goettliche Wahrheit unter dem Hut weggeklaut. Erkennt es doch endlich an!

[Xin]

CStoll schrieb:

Xin schrieb:

Du bringst vereinzelt Punkte, wo die Beibehaltung der Typsicherheit durch die Operatoren geringfügige Vorteile bringt (s.u.), aber den schätze ich nicht wichtiger ein, als die Möglichkeit Objekte zu zählen. Es bleibt bei einer Geschmackssache.

Vorteile, die dir nützen, sind von Bedeutung, Vorteile anderer Lösungen sind "geringfügig" oder "Geschmackssache" - also auf dieser Grundlage kommen wir definitiv nicht weiter.

Das ist nunmal der Punkt zu dem wir vorgestoßen sind. Wir kommen nicht weiter, weil die Designentscheidung wird eine Geschmackssache bleiben. Und über Geschmack sollte man nicht streiten.

CStoll schrieb:

Du hast damit angefangen, daß du gerne von int ableiten wolltest, ich habe dich gefragt, wofür - und seitdem versuche ich (leider erfolglos) dir zu zeigen, daß deine Lösung allen Prinzipien des OOP widerspricht.

class Integer
{
  protected:
    int IntegerValue;

  public:
    Integer( int intValue ) : IntegerValue( intValue ) {}
    int operator = ( int intValue ) { return IntegerValue = intValue; }
    operator int()                  { return IntegerValue; }    
};

class MeterOderWasAuchImmer : public Integer
{}

Es ist in C++ ausdrückbar, also machbar, es widerspricht nicht den Prinzipien von klassenorientierter Programmierung.
Auch wenn Dir das eine Beispiel nicht gefällt, dass ich auf die Schnelle ins Rennen geworfen habe, ändert das nichts daran. Ich sehe keinen Grund für eine Ableitung von Primitiven eine Sonderbedingung ("Das darfst Du nicht!") einzuführen, wenn man es über class Integer doch machen darf.

CStoll schrieb:

Xin schrieb:

CStoll schrieb:

Xin schrieb:

In der Einheit, die das Ergebnis der cosinus-Funktion bringt...?
Keine...

Gut erkannt - das bedeutet, die Rechnung "alpha = acos(distanz/hoehe);" ist absolut legal (eine einheitenlose Größe kommt vorne rein - der ArcCos macht daraus einen Winkel), die Rechnung "alpha = acos(laenge*gewicht);" ist physikalisch sinnlos (ein "kg*m" kommt rein, aber ArcCos erwartet eine einheitenlose Größe) - wird aber bei deinem Ansatz kommentarlos geschluckt.

Korrekt. Das ist ein Argument. (<- man beachte!)

Und dann kommt man zu der Frage der Wertung. Es spricht definitiv für Deinen Ansatz. Die größere Freiheit beim Zählen von Objekten für meinen. Wie oft zählt man Objekte, wie oft muss man sich dem Risiko des acos aussetzen?

Also in einer Physik-Bibliothek kommen Winkelfunktionen auf jeden Fall häufiger vor als Versuche, Meßgrößen zu "zählen".

Wow... aus einem Beispiel für eine int-Ableitung automatisch ein perfektes Typsystem entstehen, dass eine perfekte Physik-Bibliothek erzeugt, bevor einfach akzeptiert, wird, dass nichts gegen eine Ableitung von Primitiven einzuwenden ist.
Wenn Du mit dem Anspruch an Deine Software gehst, dass ein Hello World die Grundlage für ein Betriebsystem darstellen muss, dann sind wir wieder an dem Punkt, wo Dinge nicht handhabbar werden.

Erstaunlicherweise plane ich mein Ziel erstmal und lege mir dann die Techniken zurecht - nicht umgekehrt.
Wenn Du Dir also eine Technik nimmst und feststellst, dass es andere Techniken gibt, die einem Ziel besser gerecht werden, beweist du damit nicht, dass die Technik schlecht wäre.
Ohne Grundlage hebelst Du Dich leider selbst aus.

CStoll schrieb:

Es gibt immer einen größeren Zusammenhang - und vielleicht kommt die Zuweisung erst einige Ebenen weiter oben, nachdem das Zwischenergebnis weiter verrechnet wurde. Oder ich will das Ergebnis "nur" ausgeben. Oder...

Willst Du das Ergebnis weiterverrechnen, so findet eine Zuweisung statt. Willst Du das Ergebnis ausgeben, so findet eine Zuweisung statt.
Wenn Du vergißt operator << zu überladen, wenn Du das Ergebnis ausgeben möchtest, dann kann ich da auch nix dran ändern. Aber als ein Nachteil sehe ich das nicht an, die Ausgabe implizit über eine Standardfunktion zu ziehen.

CStoll schrieb:

Xin schrieb:

Das hatten wir alles schonmal. Sie sind gleichwertig, mit Ableitungen muss man lediglich etwas anders damit arbeiten, als üblich, vergleichbar mit Dot-COM-Programmierung.

Ja, das hatten wir schonmal - das Ergebnis dieser Frage ist aber irgendwo hinter der Frage "sollte man von int ableiten?" und "wie stellt man physikalische Größen in C++ am besten dar?" untergegangen.

War vermutlich meine Schuld...

CStoll schrieb:

Xin schrieb:

CStoll schrieb:

Mr.N hat vielleicht zugegeben, daß er sich "kindergartenhaft" verhält, bei einigen Unregs könnte man das aus dem Verhalten schließen - aber du stufst hier ja jeden als "Kindergarten" ein, der nicht deiner Meinung ist.

DAS halte ich für Kindergartenverhalten.

Was genau, etwa andere als "Kindergarten" einzustufen? Damit hast du angefangen und wirklich jeden "Gegner" dem Forumskindergarten zugeordnet - inklusive Shade und mir.

Nicht jeden. Dich definitiv, den Dein Verhalten in diesem Thread entspricht einem Entwickler, der nichts anderes sehen möchte, als das was er in seinen Lehrbüchern gelesen hat und als Deine sozialen Fähigkeiten als Moderator hast Du in diesem Thread definitiv nicht unter Beweis gestellt.
Shade hat sich mit seinem sagen wir mal dringenden Wunsch nach impliziten Konstruktoren in dem Thread auch nicht unbedingt mit Ruhm bekleckert.

Ich bin blöd genug, immer wieder darauf hinzuweisen, dass die Ableitungen genauso mächtig ist, wie die Komposition und mir dafür - sagen wir mal "freundlichere" Aussagen - wie "Denkfehler" und weniger freundliche wie "habe Dich für intelligent genug gehalten" von Dir anzuhören. Weiterhin stellst Du Forderungen nach Dingen, die ich nie versprochen habe: "Wo sind die Vorteile?" - ich sagte nicht, dass es Vorteile gibt, ich sagte, dass es möglich ist und dass es eine andere Sicht auf die Dinge erlaubt.
Seit 30 Seiten erzählst Du mir, dass Deine Komposition die einzige Musik ist, die hier zählt. Schön nach Schema F gestrickt, alles wunderbar, keine Frage, aber halt auch nicht besser. Dass sich hier niemand erlaubt, die Prioritäten mal anders zu legen und zu akzeptieren, dass man es genauso die Möglichkeit gibt mit Ableitungen angenehmer zu fahren, wenn man entsprechende Bedürfnisse hat, wie z.B. häufig Objekte zählt, statt sie zu multiplizieren. Das würde aber bedeuten, dass man sich auf meine Seite schlägt, was vermutlich einem sozialem Suizid in diesem Forum gleichkäme.

Ich gucke mir Deine Seite durchaus an. Vielleicht fällt es Dir auf: Ich sage gleichwertig, ich frage Dich nicht nach Vorteilen, ich kenne "Deine" Vorteile, wie ich "meine" kenne. Ich gehe nicht hin und sage, dass Du scheiße baust, weil das würde nicht stimmen. Du gehst ganz einfach nach Schema F vor und da kommt was brauchbares bei raus.

Ich sage, dass die Ableitungen durchaus etwas sinnvolles konstruieren und das kannst Du nicht widerlegen, nur weil Du Beispiele, auf die die Ableitungen nicht so gut zugeschnitten sind.
Das wäre das selbe, als würde ich mich an asInt() aufziehen, dass das das letzte wäre.

Wir zwei kommen nicht weiter, seitdem der Thread eine zweistellige Seitenzahl hat. Die meisten (wohlgemerkt nicht alle), die neben uns rum palavern, wissen in der Regel nichtmals, worum dieser Thread kreist, geschweige sind in der Lage etwas halbwegs zusammenhängendes beizutragen.
Viele machen sich einen Spaß draus, mir irgendetwas zu unterstellen und daraus Schlussfolgerungen zu ziehen, die selbstverständlich alle belegen, was für ein Arsch ich bin. Wenn das kein KiGa-Verhalten ist, dann weiß ich es auch nicht.

Hatte der Thread noch ein anderes Thema neben 'Ableitungen dürfen ausschließlich is-ein aussagen' und 'Xin ist scheiße'?
Die Masse bleibt auf diesem Standpunkt stehen und ich stimme dem so nicht zu, womit ich für die einen belege, dass 'Xin scheiße ist'. Für diejenigen ist es aber sowieso egal, egal was hier geschrieben wird, hauptsache 'Xin ist scheiße'.
Alternativ stur, ignorant, arrogant und was mir hier sonst noch vorgeworfen wird.
Für mich klingt das alles nicht sehr überzeugend, um meinen Standpunkt zu verlassen. Dein Standpunkt ist nicht falsch - meiner aber auch nicht.
Zu dem Punkt, ob ich arrogant oder ignorant oder was auch immer bin, habe ich überraschenderweise auch meinen eigenen Standpunkt.

CStoll schrieb:

Ich mag aber nicht die Rundungsprobleme von double und co. Und außerdem will ich automatisch die "richtige" bzw. passende Einheit für ein Rechenergebnis ausgegeben haben. Da wäre mein Ansatz vermutlich keine eigene Klasse, aber innerhalb der Klasse eine Trennung zwischen reinem Zahlenwert und Einheitenpräfix.

Wer mag schon Rundungsprobleme?! Aber ob Du nun ein Einheitenprefix hast oder einen Exponenten wie double: Du baust Dir Deine Rundungsprobleme von Hand nach, also wirst entsprechend leistungsfähige Datentypen verwenden müssen und dann brauchst Du keine Einheitspräfixe.

Xin schrieb:

CStoll schrieb:

Um nochmal auf dein "Produktivsystem" zurückzugehen, da ist anscheinend eine Frage untergegangen:
Ein ScreenObject (Fenster o.ä.) hat fünf "interessante Punkte", die ich abfragen und setzen möchte - vier Ecken und das Zentrum. Wie willst du (basierend auf der Ableitung von fünf Point-Derivaten) dafür sorgen, daß die Form des Objekts rechtwinklig bleibt?

Danke für die Anführungszeichen...
Ich sagte schonmal, dass ich keine Fenster in meinem Framework beschreibe...

Ansonsten funktioniert ein Setter grundsätzlich nur auf einen Datensatz. Da das Fenster die Abhängigkeit zwischen den einzelnen Datensätzen beschreibt, bedeutet das Verändern eines Punktes auch die Änderung der abhängigen Punkte.

Und das heißt in Code ausgedrückt?[/quote]
??
Das selbe, was es immer bedeutet, wenn Du Abhängigkeiten beachten musst.

Wenn Du 4 (bzw. 5) Punkten haben willst, setzt ein Setter des Fensters alle abhängigen Punkte und fertig. Gut, wenn Du alle Punkte häufig abfragst. Wenn Du Dich mit den zwei Eckpunkten zufrieden gibst, berechnest Du halt die anderen bei Abfragen.

Xin schrieb:

Und zum letzten... wer sagt denn, dass Fenster unbedingt rechtwicklig seien?! Wenn ich mir die Darstellung von 3D Fenstern ansehe, so sehen die überhaupt nicht rechtwinklig aus.

Ich - bzw. der Kunde, der von dir ein funktionsfähiges Fenster-System erwartet.[/quote]
Liebelein, ich fange mit Dir jetzt keine weitere 30 Seiten Diskussion an, um eine Möglichkeit(!) an Fenstern durchzuexerzieren. Kauf Dir ein Stofftier.

CStoll schrieb:

btw, auch wenn ich keine Ausbildung in Psychologie habe, erkenne ich bei dir trotzdem mangelnde Diskussionsbereitschaft.

Das hättest Du mir mal 30 Seiten früher vorwerfen sollen...

CStoll schrieb:

Ich würde ja gerne meinem Vater den Thread präsentieren, aber dazu ist der Thread schon zu umfangreich (und vermutlich würde er vor lauter Fachbegriffen den Überblick verlieren).

Super, Deine Oma war ja auch schon im Thread, holen wir Deinen Vater dazu.
Hast Du denn eigentlich keinen großen Bruder?

[Mr. N]

Xin schrieb:

CStoll schrieb:

Ich würde ja gerne meinem Vater den Thread präsentieren, aber dazu ist der Thread schon zu umfangreich (und vermutlich würde er vor lauter Fachbegriffen den Überblick verlieren).

Super, Deine Oma war ja auch schon im Thread, holen wir Deinen Vater dazu.
Hast Du denn eigentlich keinen großen Bruder?

Ich nehme an, sein Vater ist Psychologe.

[ValeTudo]

Ich glaub es gibt hier keinen in Forum, der so ermüdend lange Beiträge mit so wenig Inhalt schreibt.

[OMG]

Mr. N schrieb:

Xin schrieb:

CStoll schrieb:

Ich würde ja gerne meinem Vater den Thread präsentieren, aber dazu ist der Thread schon zu umfangreich (und vermutlich würde er vor lauter Fachbegriffen den Überblick verlieren).

Super, Deine Oma war ja auch schon im Thread, holen wir Deinen Vater dazu.
Hast Du denn eigentlich keinen großen Bruder?

Ich nehme an, sein Vater ist Psychologe.

So, nun haben wir die nächste Aussage, deren implizite Konstruktion Xin nicht verstanden hat, und die ein Ausweichthema für ihn auf den nächsten 10 Seiten liefert.

[CStoll]

Xin schrieb:

CStoll schrieb:

Du hast damit angefangen, daß du gerne von int ableiten wolltest, ich habe dich gefragt, wofür - und seitdem versuche ich (leider erfolglos) dir zu zeigen, daß deine Lösung allen Prinzipien des OOP widerspricht.

class Integer
{
  protected:
    int IntegerValue;

  public:
    Integer( int intValue ) : IntegerValue( intValue ) {}
    int operator = ( int intValue ) { return IntegerValue = intValue; }
    operator int()                  { return IntegerValue; }    
};

class MeterOderWasAuchImmer : public Integer
{}

Es ist in C++ ausdrückbar, also machbar, es widerspricht nicht den Prinzipien von klassenorientierter Programmierung.
Auch wenn Dir das eine Beispiel nicht gefällt, dass ich auf die Schnelle ins Rennen geworfen habe, ändert das nichts daran. Ich sehe keinen Grund für eine Ableitung von Primitiven eine Sonderbedingung ("Das darfst Du nicht!") einzuführen, wenn man es über class Integer doch machen darf.

Ja, soweit waren wir schonmal - aber bisher hast du mir immer noch nicht erklärt, was für einen Sinn so eine Konstruktion bringen soll. Die damit verbundene implizite Typumwandlung nach int halte ich für einen gravierenden Nachteil (OK, du stufst sie lediglich als "Geschmacksfrage ab), also müsstest du schon einen ausreichenden Vorteil präsentieren, um ihn zu kompensieren - diesen Vorteil sehe ich bisher nicht.
(und wenn Lösung A gegenüber Lösung B zwar einen deutlich ersichtlichen Nachteil, aber keine erkennbaren Vorteile hat, sind sie nicht gleichwertig)

Xin schrieb:

CStoll schrieb:

Xin schrieb:

CStoll schrieb:

Xin schrieb:

In der Einheit, die das Ergebnis der cosinus-Funktion bringt...?
Keine...

Gut erkannt - das bedeutet, die Rechnung "alpha = acos(distanz/hoehe);" ist absolut legal (eine einheitenlose Größe kommt vorne rein - der ArcCos macht daraus einen Winkel), die Rechnung "alpha = acos(laenge*gewicht);" ist physikalisch sinnlos (ein "kg*m" kommt rein, aber ArcCos erwartet eine einheitenlose Größe) - wird aber bei deinem Ansatz kommentarlos geschluckt.

Korrekt. Das ist ein Argument. (<- man beachte!)

Und dann kommt man zu der Frage der Wertung. Es spricht definitiv für Deinen Ansatz. Die größere Freiheit beim Zählen von Objekten für meinen. Wie oft zählt man Objekte, wie oft muss man sich dem Risiko des acos aussetzen?

Also in einer Physik-Bibliothek kommen Winkelfunktionen auf jeden Fall häufiger vor als Versuche, Meßgrößen zu "zählen".

Wow... aus einem Beispiel für eine int-Ableitung automatisch ein perfektes Typsystem entstehen, dass eine perfekte Physik-Bibliothek erzeugt, bevor einfach akzeptiert, wird, dass nichts gegen eine Ableitung von Primitiven einzuwenden ist.
Wenn Du mit dem Anspruch an Deine Software gehst, dass ein Hello World die Grundlage für ein Betriebsystem darstellen muss, dann sind wir wieder an dem Punkt, wo Dinge nicht handhabbar werden.

Nein, ich gehe mit dem Ansatz heran, ein Typ-System zu entwickeln, das mir die Arbeit abnimmt. Und wenn ich mir die Alternativen zur Wertrepräsentation ansehe, betrachte ich alle Vor- und Nachteile und wäge ab, welche davon wichtiger sind - in dem Fall halte ich die Lösung über Komposition für besser tauglich.

Wenn du mich wirklich überzeugen willst, irgendwann von int ableiten zu wollen, solltest du entweder ein besseres Beispiel bringen, wo es Sinn macht - oder mir nochmal erklären, was deine Lösung(das Konzept stammte letztendlich von dir) gegenüber dem "klassischen" Lösungsweg 'gleichwertig' macht. (diese Aussage von dir steht immer noch im Raum, und wurde nur "bewiesen", indem du alle Gegenargumente (unbegründet) als "Geschmacksfrage" deklariert hast)

Xin schrieb:

Wenn Du Dir also eine Technik nimmst und feststellst, dass es andere Techniken gibt, die einem Ziel besser gerecht werden, beweist du damit nicht, dass die Technik schlecht wäre.
Ohne Grundlage hebelst Du Dich leider selbst aus.

Dann liefere mir doch eine Grundlage - gib mir eine mögliche Anwendung, wo ich mit einer Ableitung von int besser fahren würde als mit "meiner" Komposition. Irgendeinen Bereich muß es ja geben, wo diese Technik optimal ist, andernfalls ist sie nutzlos.

Xin schrieb:

CStoll schrieb:

Es gibt immer einen größeren Zusammenhang - und vielleicht kommt die Zuweisung erst einige Ebenen weiter oben, nachdem das Zwischenergebnis weiter verrechnet wurde. Oder ich will das Ergebnis "nur" ausgeben. Oder...

Willst Du das Ergebnis weiterverrechnen, so findet eine Zuweisung statt. Willst Du das Ergebnis ausgeben, so findet eine Zuweisung statt.
Wenn Du vergißt operator << zu überladen, wenn Du das Ergebnis ausgeben möchtest, dann kann ich da auch nix dran ändern. Aber als ein Nachteil sehe ich das nicht an, die Ausgabe implizit über eine Standardfunktion zu ziehen.

Ich habe ja einen Ausgabeoperator für meine Typen - nur was nützt der mir, wenn irgendein Zwischenwert der Rechnung seine Einheit unterwegs verloren hat und nun doch der falsche Ausgabe-Operator aufgerufen wird.

Xin schrieb:

CStoll schrieb:

Xin schrieb:

CStoll schrieb:

Mr.N hat vielleicht zugegeben, daß er sich "kindergartenhaft" verhält, bei einigen Unregs könnte man das aus dem Verhalten schließen - aber du stufst hier ja jeden als "Kindergarten" ein, der nicht deiner Meinung ist.

DAS halte ich für Kindergartenverhalten.

Was genau, etwa andere als "Kindergarten" einzustufen? Damit hast du angefangen und wirklich jeden "Gegner" dem Forumskindergarten zugeordnet - inklusive Shade und mir.

Nicht jeden. Dich definitiv, den Dein Verhalten in diesem Thread entspricht einem Entwickler, der nichts anderes sehen möchte, als das was er in seinen Lehrbüchern gelesen hat und als Deine sozialen Fähigkeiten als Moderator hast Du in diesem Thread definitiv nicht unter Beweis gestellt.
Shade hat sich mit seinem sagen wir mal dringenden Wunsch nach impliziten Konstruktoren in dem Thread auch nicht unbedingt mit Ruhm bekleckert.

Ich bin blöd genug, immer wieder darauf hinzuweisen, dass die Ableitungen genauso mächtig ist, wie die Komposition und mir dafür - sagen wir mal "freundlichere" Aussagen - wie "Denkfehler" und weniger freundliche wie "habe Dich für intelligent genug gehalten" von Dir anzuhören. Weiterhin stellst Du Forderungen nach Dingen, die ich nie versprochen habe: "Wo sind die Vorteile?" - ich sagte nicht, dass es Vorteile gibt, ich sagte, dass es möglich ist und dass es eine andere Sicht auf die Dinge erlaubt.
Seit 30 Seiten erzählst Du mir, dass Deine Komposition die einzige Musik ist, die hier zählt. Schön nach Schema F gestrickt, alles wunderbar, keine Frage, aber halt auch nicht besser. Dass sich hier niemand erlaubt, die Prioritäten mal anders zu legen und zu akzeptieren, dass man es genauso die Möglichkeit gibt mit Ableitungen angenehmer zu fahren, wenn man entsprechende Bedürfnisse hat, wie z.B. häufig Objekte zählt, statt sie zu multiplizieren. Das würde aber bedeuten, dass man sich auf meine Seite schlägt, was vermutlich einem sozialem Suizid in diesem Forum gleichkäme.

Und ich habe dich wiederholt darauf hingewiesen, daß es einen konzeptionellen Unterschied zwischen Ableitung und Komposition gibt (wenn sie identisch/gleichwertig wären, gäbe es wohl keinen Grund, zwei Lösungen für das selbe anzubieten). Ableitungen sind sinnvoll, wenn man sich ihrer Bedeutung klar ist (und wo sie passen, setze ich sie auch ein), aber alles mittels Ableitung darstellen zu wollen, ist Humbug.
(ich glaube du warst es, der den Vergleich mit dem Holzhammer gebracht hatte)

Xin schrieb:

Ich gucke mir Deine Seite durchaus an. Vielleicht fällt es Dir auf: Ich sage gleichwertig, ich frage Dich nicht nach Vorteilen, ich kenne "Deine" Vorteile, wie ich "meine" kenne. Ich gehe nicht hin und sage, dass Du scheiße baust, weil das würde nicht stimmen. Du gehst ganz einfach nach Schema F vor und da kommt was brauchbares bei raus.

Wenn du deine Vorteile kennst, dann teile diese Erkenntnisse doch mit anderen Dein System hat Nachteile - und wenn du nicht irgendwas als Ausgleich bietest, ist es nicht gleichwertig.

Xin schrieb:

Wir zwei kommen nicht weiter, seitdem der Thread eine zweistellige Seitenzahl hat. Die meisten (wohlgemerkt nicht alle), die neben uns rum palavern, wissen in der Regel nichtmals, worum dieser Thread kreist, geschweige sind in der Lage etwas halbwegs zusammenhängendes beizutragen.
Viele machen sich einen Spaß draus, mir irgendetwas zu unterstellen und daraus Schlussfolgerungen zu ziehen, die selbstverständlich alle belegen, was für ein ***** ich bin. Wenn das kein KiGa-Verhalten ist, dann weiß ich es auch nicht.

Ja, wir zwei kommen nicht weiter - aber das ist bestimmt nicht alleine meine Schuld (vielleicht zum Teil).

Xin schrieb:

Hatte der Thread noch ein anderes Thema neben 'Ableitungen dürfen ausschließlich is-ein aussagen' und 'Xin ist scheiße'?
Die Masse bleibt auf diesem Standpunkt stehen und ich stimme dem so nicht zu, womit ich für die einen belege, dass 'Xin scheiße ist'. Für diejenigen ist es aber sowieso egal, egal was hier geschrieben wird, hauptsache 'Xin ist scheiße'.
Alternativ stur, ignorant, arrogant und was mir hier sonst noch vorgeworfen wird.
Für mich klingt das alles nicht sehr überzeugend, um meinen Standpunkt zu verlassen. Dein Standpunkt ist nicht falsch - meiner aber auch nicht.
Zu dem Punkt, ob ich arrogant oder ignorant oder was auch immer bin, habe ich überraschenderweise auch meinen eigenen Standpunkt.

"Xin ist scheiße" hast du in das Thema reininterpretiert. Ich habe mich bemüht, dir (konstruktiv) klarzumachen, was an deinem Weg falsch ist (an einem Beispiel, das du ausgewählt hast).

Xin schrieb:

Xin schrieb:

CStoll schrieb:

Um nochmal auf dein "Produktivsystem" zurückzugehen, da ist anscheinend eine Frage untergegangen:
Ein ScreenObject (Fenster o.ä.) hat fünf "interessante Punkte", die ich abfragen und setzen möchte - vier Ecken und das Zentrum. Wie willst du (basierend auf der Ableitung von fünf Point-Derivaten) dafür sorgen, daß die Form des Objekts rechtwinklig bleibt?

Danke für die Anführungszeichen...
Ich sagte schonmal, dass ich keine Fenster in meinem Framework beschreibe...

Ansonsten funktioniert ein Setter grundsätzlich nur auf einen Datensatz. Da das Fenster die Abhängigkeit zwischen den einzelnen Datensätzen beschreibt, bedeutet das Verändern eines Punktes auch die Änderung der abhängigen Punkte.

Und das heißt in Code ausgedrückt?

??
Das selbe, was es immer bedeutet, wenn Du Abhängigkeiten beachten musst.

Wenn Du 4 (bzw. 5) Punkten haben willst, setzt ein Setter des Fensters alle abhängigen Punkte und fertig. Gut, wenn Du alle Punkte häufig abfragst. Wenn Du Dich mit den zwei Eckpunkten zufrieden gibst, berechnest Du halt die anderen bei Abfragen.

Und wer wählt aus, welche Punkte des Fensters nun per Getter gesucht werden und welche über Typumwandlungen? Du hast als einen Vorteil deines Ansatzes präsentiert, daß ich mit "my_area = PointUpperLeft(47,11);" das Fenster strecken kann - also wie würde das in Quellcode umgesetzt werden?

Bei diesem Weg hast du entweder Redundanzen (UpperLeft und UpperRight haben die selbe x-Koordinate) oder Inkonsistenzen (UpperLeft wird per Zuweisung korrigiert, UpperRight per Setter). Was ist dir lieber?

Xin schrieb:

Xin schrieb:

Und zum letzten... wer sagt denn, dass Fenster unbedingt rechtwicklig seien?! Wenn ich mir die Darstellung von 3D Fenstern ansehe, so sehen die überhaupt nicht rechtwinklig aus.

Ich - bzw. der Kunde, der von dir ein funktionsfähiges Fenster-System erwartet.

Liebelein, ich fange mit Dir jetzt keine weitere 30 Seiten Diskussion an, um eine Möglichkeit(!) an Fenstern durchzuexerzieren. Kauf Dir ein Stofftier.

Muß ich mich dazu noch äußern?

Btw, noch ein Wort zur Bezeichnung "Produktivsystem": Normalerweise gibt es einen Entwickler und viele Anwender (dazu gehören auch andere Entwickler, die deine Bibliothek in ihren Programmen nutzen wollen). Solange du auf dem Standpunkt stehst, daß bestenfalls drei bis vier Leute mit deinem System umgehen wollen/sollen/..., brauchst du nicht wirklich von Produktivsystem zu sprechen.

Xin schrieb:

CStoll schrieb:

btw, auch wenn ich keine Ausbildung in Psychologie habe, erkenne ich bei dir trotzdem mangelnde Diskussionsbereitschaft.

Das hättest Du mir mal 30 Seiten früher vorwerfen sollen...

Ich hab's ja versucht.

Mr. N schrieb:

Xin schrieb:

CStoll schrieb:

Ich würde ja gerne meinem Vater den Thread präsentieren, aber dazu ist der Thread schon zu umfangreich (und vermutlich würde er vor lauter Fachbegriffen den Überblick verlieren).

Super, Deine Oma war ja auch schon im Thread, holen wir Deinen Vater dazu.
Hast Du denn eigentlich keinen großen Bruder?

Ich nehme an, sein Vater ist Psychologe.

Fast - er ist Lehrer.
Und er würde Xin wohl mangelnde Sozialkompetenz diagnostizieren (ein Tip: zur Kritikfähigkeit gehört es auch, Kritik aufzunehmen und darüber nachzudenken).

[Tellerrand]

CStoll schrieb:

Ja, soweit waren wir schonmal - aber bisher hast du mir immer noch nicht erklärt, was für einen Sinn so eine Konstruktion bringen soll. Die damit verbundene implizite Typumwandlung nach int halte ich für einen gravierenden Nachteil (OK, du stufst sie lediglich als "Geschmacksfrage ab), also müsstest du schon einen ausreichenden Vorteil präsentieren, um ihn zu kompensieren - diesen Vorteil sehe ich bisher nicht.
(und wenn Lösung A gegenüber Lösung B zwar einen deutlich ersichtlichen Nachteil, aber keine erkennbaren Vorteile hat, sind sie nicht gleichwertig)

Wenn man etwas als Geschmacksfrage einstuft, dann braucht man keinen Vorteil zu präsentieren.
Die Nachteile bügelt er doch über Restriktionen und Begrenzungen aus, damit existieren diese Nachteile nichtmehr.

Das man nun z.B keine impliziten Konstruktoren, keine komplexen Umwandlungen per Operatoren oder keine redundanten Datentypen verwenden darf ist doch kein Nachteil!
Es ist ja auch kein Nachteil, dass man nicht gesagt bekommt wo der Typverlust stattfindet.

Das ist doch alles eine Geschmacksfrage!

[Aprollo]

Ableitung und Kompsition o.O

Class A
Class B

Class B : public A
Mit ne Vererbung sag ich, B ist von Type A und erweiter sich um sich selbst.

Class B {
Class A _a;
}
Mit eine Kompsition sag ich dass B A enthält und erweitere es um sich selbst, aber es ist kein Type von A!

[Xin.]

Aprollo schrieb:

Ableitung und Kompsition o.O

Class A
Class B

Class B : public A
Mit ne Vererbung sag ich, B ist von Type A und erweiter sich um sich selbst.

Class B {
Class A _a;
}
Mit eine Kompsition sag ich dass B A enthält und erweitere es um sich selbst, aber es ist kein Type von A!

Wenn Xin sagt, das ist das Gleiche, dann wird das ja wohl stimmen.

[Xin]

CStoll schrieb:

Ja, soweit waren wir schonmal - aber bisher hast du mir immer noch nicht erklärt, was für einen Sinn so eine Konstruktion bringen soll. Die damit verbundene implizite Typumwandlung nach int halte ich für einen gravierenden Nachteil (OK, du stufst sie lediglich als "Geschmacksfrage ab), also müsstest du schon einen ausreichenden Vorteil präsentieren, um ihn zu kompensieren - diesen Vorteil sehe ich bisher nicht.

Falsch, ich brauche keinen Vorteil, ich brauche nichtmals Gleichwertigkeit, um eine Möglichkeit anzubieten. Ich sehe sie gleichwertig, Du nicht.

CStoll schrieb:

Xin schrieb:

Wow... aus einem Beispiel für eine int-Ableitung automatisch ein perfektes Typsystem entstehen, dass eine perfekte Physik-Bibliothek erzeugt, bevor einfach akzeptiert, wird, dass nichts gegen eine Ableitung von Primitiven einzuwenden ist.
Wenn Du mit dem Anspruch an Deine Software gehst, dass ein Hello World die Grundlage für ein Betriebsystem darstellen muss, dann sind wir wieder an dem Punkt, wo Dinge nicht handhabbar werden.

Nein, ich gehe mit dem Ansatz heran, ein Typ-System zu entwickeln, das mir die Arbeit abnimmt.

Dein Ansatz war "Xin, zeige ein Beispiel für eine int-Ableitung", "Xin mache daraus das perfekte Typsystem", "Xin mache daraus eine Physik-Lib".

Schrieb ich schon, dass ich üblicherweise Techniken aussuche, um ein Problem zu beschreiben, und mir nicht Probleme auszusuche, um eine Technik zu verwenden? Ja, schrieb ich schon.

Und weil eigentlich alles schon geschrieben wurde, hält sich seit vielen Seiten der Sinn dieses Threads in sehr engen Grenzen.

CStoll schrieb:

Wenn du mich wirklich überzeugen willst

Ich will Dich nicht überzeugen. Schrieb ich schon.
Ich gebe eine Möglichkeit vor, die ist da, die ist so und die ist nicht wegzudiskutieren. Punkt.
Und man kann sie auch benutzen, wenn man sie für angebracht hält. Ich bin der Meinung, dass man mehr mit Ableitungen arbeiten kann, Du nicht. Beides hat Vor- und Nachteile => Geschmackssache, Thema für mich erledigt.

CStoll schrieb:

Xin schrieb:

Wenn Du Dir also eine Technik nimmst und feststellst, dass es andere Techniken gibt, die einem Ziel besser gerecht werden, beweist du damit nicht, dass die Technik schlecht wäre.
Ohne Grundlage hebelst Du Dich leider selbst aus.

Dann liefere mir doch eine Grundlage - gib mir eine mögliche Anwendung, wo ich mit einer Ableitung von int besser fahren würde als mit "meiner" Komposition. Irgendeinen Bereich muß es ja geben, wo diese Technik optimal ist, andernfalls ist sie nutzlos.

Ich sehe interessante Möglichkeiten, bei großen Frameworks, die somit zum einen dafür sorgen, dass Typen nicht für unpassende Informationen verwendet werden und zum anderen garantieren, dass jedes Objekt gleichartig Informationen auf- und wieder abgibt. Schrieb ich schon.

Nein, ich schreibe Dir kein großes Framework, damit Du es erkennst.

CStoll schrieb:

Und ich habe dich wiederholt darauf hingewiesen, daß es einen konzeptionellen Unterschied zwischen Ableitung und Komposition gibt (wenn sie identisch/gleichwertig wären, gäbe es wohl keinen Grund, zwei Lösungen für das selbe anzubieten).

Es ist ein sprachsemantischer Unterschied, kein Unterschied in den Möglichkeiten, kein Unterschied der den Compiler überlebt. Es ist die Aussage darüber, was als implizit gilt und was als explizit angegeben werden muss.

CStoll schrieb:

Ja, wir zwei kommen nicht weiter - aber das ist bestimmt nicht alleine meine Schuld (vielleicht zum Teil).

Sehe ich für mich ähnlich.

Interessiert mich das, um hier Schuldfragen zu klären?
Bin ich hier, um herauszufinden, wer an irgendwas Schuld trägt?
Nein.

Ich bin an Austausch interessiert.
Wenn Du mit mir 3D Welten erzeugen willst, bin ich interessiert, davon verstehe ich nicht viel.
Wenn es aber um Dinge, geht die eine Programmiersprache ausmachen, wie die Möglichkeiten die Ableitung und Komposition bieten, oder was die Definition von OOP angeht, dann habe ich ein recht sicheres Fundament.
Bei OOP gibt es keine Alternative, sofern man nicht in eine schwammige Definition verkommen will.
Hier gibt es Möglichkeiten, die gleichwertig sind: Komposition und Vererbung. Ein paar Spielregeln ändern sich, weil durch die Ableitung mehr implizite Dinge stattfinden, die im Fall von acos() unpraktisch sind.
Dafür ist genau das praktisch, beim durchzählen von Objekten (Warenwirtschaft) oder bei der Verwendung mit Schnittstellen, die diese Typen nicht kennen.
Nicht jedes Programm braucht laufend acos(). Damit verschieben sich die Prioritäten man kann sich überlegen, je nach Situation überlegen, was man braucht. Es wird zu einer Geschmackssache - situationsabhängig, es gibt kein Gut und kein Böse, das allgemein gilt. Es gibt nur zwei Möglichkeiten und das muss so anerkannt werden.

CStoll schrieb:

"Xin ist scheiße" hast du in das Thema reininterpretiert. Ich habe mich bemüht, dir (konstruktiv) klarzumachen, was an deinem Weg falsch ist (an einem Beispiel, das du ausgewählt hast).

*lach*, ich sehe hier nicht, wo ich interpretieren müsste.
Konstruktiv wäre gewesen, wenn Du eine Idee auffasst und die Möglichkeiten und Unmöglichkeiten auslotest. Du hast die Idee aus einem dahergeworfenen Beispiel genommen, das gleiche über die Komposition erstellt und es dann auf einen Crashtest angelegt.
Wenn ich für ein dahergeworfenes Beispiel erst Crashtests machen muss, dann wäre es von Vorteil, wenn Du das vorher ankündigst, so dass ich das Beispiel entsprechend gestalten kann.
Ich habe nie versprochen, dass mein Modell Crashtest sicher wäre. Es war ein Beispiel, um die Idee dahinter zu verdeutlichen. Trotzdem schlägt es nicht wirklich schlechter als die Komposition, denn es bringt nichts einen Crashtest unter ungleichen Bedingungen zu fahren.
Du hast ein dahergebrachtes Beispiel genommen, sämtliche Rahmenbedingungen festgelegt und willst so beweisen, dass
ich etwas nicht einhalte, was ich nichtmals versprochen habe. Und blöderweise fällt "mein" Model auch nicht gleich auseinander, nur weil Du es gegen mal gegen die Wand gefahren hast.
An beiden Modellen sind nach Deinen Crashtests jetzt hier und da ein paar Kratzer dran - ich lasse mich aber nicht auf ein grundsätzliches Urteil herab. Das kann jeder selbst aussuchen, wo er mit Kratzern leben kann und wo nicht.
Für Dich gilt nur "Es darf nicht sein, so muss es zerschlagen werden.". Dafür greifst Du Dir 50 Jahre Programmierwissen, um auf eine mal eben geborene Idee zu feuern.
Einen konstruktiven Diskussionsparter stellst Du jedenfalls so nicht dar. Du willst die Idee kaputtkriegen. Konstruktiv wäre gewesen, sie wachsen zu lassen und dann zu gucken, was Du individuell damit anfangen kannst.
Neue Konzepte fallen nicht einfach vom Himmel. Neue Konzepte sind auch nicht immer mit C++ direkt zu übersetzen.

Die Möglichkeit, sich derart auszudrücken, existiert und egal, wieviel Du daran rumzunörgeln hast - sie steht immernoch.
Leb damit, Du musst sie ja nicht nutzen. (Schrieb ich auch schon...)

CStoll schrieb:

Und wer wählt aus, welche Punkte des Fensters nun per Getter gesucht werden und welche über Typumwandlungen?

Keine Komposition => keine Getter erforderlich.
Wer das auswählt: Der Entwickler der Klasse, war das früher was anderes?

CStoll schrieb:

Du hast als einen Vorteil deines Ansatzes präsentiert, daß ich mit "my_area = PointUpperLeft(47,11);" das Fenster strecken kann - also wie würde das in Quellcode umgesetzt werden?
Bei diesem Weg hast du entweder Redundanzen (UpperLeft und UpperRight haben die selbe x-Koordinate) oder Inkonsistenzen (UpperLeft wird per Zuweisung korrigiert, UpperRight per Setter). Was ist dir lieber?

Keine Ahnung, wo Du Inkonsequenzen siehst, ich sehe bestenfalls Programmierfehler und Programmierfehler habe ich auch nicht erfunden, die gibt's schon länger - auch bei Komposition.

Wieder ein schönes Feuerwerk an Text und doch nur heiße Luft.

CStoll schrieb:

Xin schrieb:

CStoll schrieb:

Ich - bzw. der Kunde, der von dir ein funktionsfähiges Fenster-System erwartet.

Liebelein, ich fange mit Dir jetzt keine weitere 30 Seiten Diskussion an, um eine Möglichkeit(!) an Fenstern durchzuexerzieren. Kauf Dir ein Stofftier.

Muß ich mich dazu noch äußern?

Nein.
Was das Stofftier angeht, so gehe ich mal davon aus, dass Du das nicht verstehen kannst, es war eher eine Art "Insider": Ein Prof riet uns in seiner Vorlesung, uns ein Stofftier anzuschaffen. Es hört zu und hilft Gedanken zu sortieren, da man sie ausformuliert.
Es hatte nichts mit (Kindergarten-)Kindern zu tun.

Weitere Äußerungen sind allerdings wirklich nicht erforderlich.

CStoll schrieb:

Btw, noch ein Wort zur Bezeichnung "Produktivsystem": Normalerweise gibt es einen Entwickler und viele Anwender (dazu gehören auch andere Entwickler, die deine Bibliothek in ihren Programmen nutzen wollen). Solange du auf dem Standpunkt stehst, daß bestenfalls drei bis vier Leute mit deinem System umgehen wollen/sollen/..., brauchst du nicht wirklich von Produktivsystem zu sprechen.

Es ist produktiv im Einsatz, aber nicht öffentlich verfügbar. Wollen wir hier die Unterschiede von "produktiv im Einsatz" und "Produktivsystem" klären?

CStoll schrieb:

Mr. N schrieb:

Xin schrieb:

CStoll schrieb:

Ich würde ja gerne meinem Vater den Thread präsentieren, aber dazu ist der Thread schon zu umfangreich (und vermutlich würde er vor lauter Fachbegriffen den Überblick verlieren).

Super, Deine Oma war ja auch schon im Thread, holen wir Deinen Vater dazu.
Hast Du denn eigentlich keinen großen Bruder?

Ich nehme an, sein Vater ist Psychologe.

Fast - er ist Lehrer.

Hmm... meiner (natürlich nicht allgemeinverbindlichen) Erfahrung von Pädagogenkindern bzw. Pädagogen als Eltern nach, hätte ein Warnhinweis in Deiner Signatur die Diskussion verkürzen können.
Sieh es positiv. Wir haben auch mehrere Psychologen im Bekanntenkreis. Also würde ich sagen, Dein Status als "Pädagogenkind" ist immernoch besser, als "Psychaterkind".

OMG schrieb:

Mr. N schrieb:

Ich nehme an, sein Vater ist Psychologe.

So, nun haben wir die nächste Aussage, deren implizite Konstruktion Xin nicht verstanden hat, und die ein Ausweichthema für ihn auf den nächsten 10 Seiten liefert.

Danke für diesen konstruktiven Beitrag, der belegt wie wichtig explizite Konstruktoren sind. Sie sind leider auf implizite Konstruktoren reingefallen und konnten den Beruf nicht daher typsicher zuordnen.

CStoll schrieb:

Und er würde Xin wohl mangelnde Sozialkompetenz diagnostizieren (ein Tip: zur Kritikfähigkeit gehört es auch, Kritik aufzunehmen und darüber nachzudenken).

Dein Vater ist Lehrer, kein Arzt.
Weiterhin schreibt hier nicht der Lehrer, sondern der Student.

Ich bezweifle, dass Du jemanden findest, der selbstkritischer ist als ich.
Ich stelle mein Wissen und meine Meinungen regelmäßig in Frage. Allerdings ziehe ich aus meiner Selbstkritik nicht nur Selbstzweifel. Ich bemühe mich meine Überzeugungen über eine Vielzahl von Wegen zu belegen. Wenn's richtig ist, muss auf allen Wegen das selbe rauskommen. Und das mache ich jetzt schon was länger so.
Und immer wieder trifft man auf Leute wie Dich, die gegangene Pfade nicht verlassen wollen und alles als falsch deklarieren, was nicht dem "üblichen" entspricht. Manche begehen recht einfache logische Fehler, die schnell auffallen, wie OMGs Feststellung, dass ich implizite Konstrukte nicht verstehen würde und durch sein implizites Mißverstehen leider selbst disqualifiziert. Macht ja nichts, solange man zu feige ist, eine Identität in die Waagschale zu legen.
Es sind auch schon Fälle dabei gewesen, die jahrelang gegen mich sticheln und mich für ignorant, arrogant usw. erklärten und wirklich böswillig gegen mich vorgingen, mir die Worte im Mund herumdrehten und damit auch erstmal kraftig Aufwind bekamen. Auf einer Welle mitschwimmen ist schließlich nicht schwer.
Die Welle bricht entweder mich oder die Welle bricht an mir.
Es ist noch kein Fall dabei gewesen, wo ein Derartiger sich auf Dauer nicht selbst mehr geschadet hat als mir oder ich einer Welle aus dem Weg gehen musste. Mit ein wenig Geduld hängt sich jeder irgendwann zu weit aus dem Fenster und stützt, dafür muss ich nicht eingreifen. Ich muss niemanden ans Fenster bringen, noch rausstoßen - aber ich fange auch nur die wenigsten auf.
Nur die Unregistrierten können sicher sein, dass sie nicht tief fallen.

Es gibt aber auch immer wieder Leute, die sich die Mühe machen, mich kennenzulernen. Das sind die Menschen, die wissen, dass ich sehr genau weiß, was ich weiß, wo ich mir "nur" sicher bin und dass ich ansonsten auch sage, dass ich etwas nicht weiß. Und die wissen auch zu schätzen, dass ich Ideen, die mich nicht begeistern trotzdem aufnehme und weiterführe, bis wir wissen, ob sie mich entweder doch noch inspirieren, sie nicht besser oder schlechter ist als anderes oder derjenige einen Überblick seiner Möglichkeiten erhalten hat.

Dieser Thread war inspirierend - nur leider musste ich den inspirierenden Part für mich selbst übernehmen.

[Gast]

Hallo

Xin schrieb:

Ich bezweifle, dass Du jemanden findest, der selbstkritischer ist als ich.

Der Satz des Jahres.

chrische

[Undertaker]

chrische5 schrieb:

Hallo

Xin schrieb:

Ich bezweifle, dass Du jemanden findest, der selbstkritischer ist als ich.

Der Satz des Jahres.

muss ja richtig spass machen, einen sündenbock zu haben

[Mr. N]

Undertaker schrieb:

chrische5 schrieb:

Hallo

Xin schrieb:

Ich bezweifle, dass Du jemanden findest, der selbstkritischer ist als ich.

Der Satz des Jahres.

muss ja richtig spass machen, einen sündenbock zu haben

Liest du überhaupt, was Xin schreibt? "Sündenbock" ist nicht das passende Wort.

[Undertaker]

Mr. N schrieb:

Liest du überhaupt, was Xin schreibt?

klar, ich finde es teilweise ziemlich interessant.

Mr. N schrieb:

"Sündenbock" ist nicht das passende Wort.

vielleicht nicht. jedenfalls finde ich's blöd, dass viele ihn so dumm anzicken, auch leute (regs und unregs gleichermassen), die mit der diskussion eigentlich gar nichts zu tun haben.

[Mr. N]

Undertaker schrieb:

Mr. N schrieb:

Liest du überhaupt, was Xin schreibt?

klar, ich finde es teilweise ziemlich interessant.

Ich finde es vor allem beleidigend und blödsinnig. Wenn er zum Beispiel CStoll (dessen einziger Fehler hier: übermäßiger Optimismus) als "Liebelein" anredet, dann ist das eine Beleidigung, bei der mir sofort der Kragen platzen würde. [Aber ich bin ja auch ein *****. :)]

Undertaker schrieb:

Mr. N schrieb:

"Sündenbock" ist nicht das passende Wort.

vielleicht nicht. jedenfalls finde ich's blöd, dass viele ihn so dumm anzicken, auch leute (regs und unregs gleichermassen), die mit der diskussion eigentlich gar nichts zu tun haben.

Ich kann immer noch nicht glauben, dass du wirklich Xins Beiträge gelesen hast. Hattest du ne rosa Sonnenbrille an?

[Undertaker]

Mr. N schrieb:

Ich kann immer noch nicht glauben, dass du wirklich Xins Beiträge gelesen hast. Hattest du ne rosa Sonnenbrille an?

die hab' ich *immer* auf. ich suche mir nur die für mich interessanten sachen raus. das gegenseitige angezicke nehme ich gar nicht wahr.

[Theston]

Undertaker schrieb:

jedenfalls finde ich's blöd, dass viele ihn so dumm anzicken, auch leute (regs und unregs gleichermassen), die mit der diskussion eigentlich gar nichts zu tun haben.

Und warum glaubst du, dass das so ist?
Das kommt vielleicht jetzt als Schock für Xin, aber: Die Reaktionen auf ihn sind allein seinem Verhalten geschuldigt, Marc++us hat das Board damals meines Wissens nicht mit dem Ziel erstellt, eine Plattform gegen Xin aufzubauen.

[Undertaker]

Theston schrieb:

Undertaker schrieb:

jedenfalls finde ich's blöd, dass viele ihn so dumm anzicken, auch leute (regs und unregs gleichermassen), die mit der diskussion eigentlich gar nichts zu tun haben.

Und warum glaubst du, dass das so ist?

vielleicht empfinden sie's als persönliche beleidigung, wenn jemand so massiv an ihrem festgefahrenen weltbild rüttelt. vielleicht ist es eine art 'lynchmob'-verhalten, alle auf einen, nur in der menge bin ich stark. keine ahnung, dazu fehlt mir das psychologische wissen.

[Mr. N]

Undertaker schrieb:

Theston schrieb:

Undertaker schrieb:

jedenfalls finde ich's blöd, dass viele ihn so dumm anzicken, auch leute (regs und unregs gleichermassen), die mit der diskussion eigentlich gar nichts zu tun haben.

Und warum glaubst du, dass das so ist?

vielleicht empfinden sie's als persönliche beleidigung, wenn jemand so massiv an ihrem festgefahrenen weltbild rüttelt. vielleicht ist es eine art 'lynchmob'-verhalten, alle auf einen, nur in der menge bin ich stark. keine ahnung, dazu fehlt mir das psychologische wissen.

Die Erklärung, dass man mit 38 Seiten inhaltlichen Unfugs und Beleidigungen gegen alles und jeden eben auch fast jeden auf die Palme bringen könnte, wäre zu einfach?

[Gast]

Theston schrieb:

Undertaker schrieb:

jedenfalls finde ich's blöd, dass viele ihn so dumm anzicken, auch leute (regs und unregs gleichermassen), die mit der diskussion eigentlich gar nichts zu tun haben.

Und warum glaubst du, dass das so ist?

Vielleicht weil das Forum hier als ein Forum für Problemlösungen und Hotfix-Ratschlägen begriffen wird ?

Und Xin seinen Ansatz nicht gelöst haben wollte sondern weiterentwickelt ?