Performancemythen?

[DEvent]

Seite 46

Xin schrieb:

Herzen können schlagen, Menschen auch.
Trotzdem besteht zwischen dem Objekt Herz und dem Objekt Mensch keine Beziehung, bei der schlagen() durch eine gemeinsame, überschreibbare Methode beschrieben werden kann.

Obwohl beides schlägt, besteht hier ein guter Grund, kein Interface und damit auch keine Beziehung herzustellen, also damit auch OOP auszuschließen.
Objekt::schlagen() ist einmal lebenserhaltend, konstruktiv und notwendig und einmal lebensgefährlich, destruktiv und überflüssig. Semantisch haben beide schlagen() keine sinnvolle Gemeinsamkeiten.
Das ist sogar ein guter Grund hier keine Templates zu verwenden, obwohl Templates nicht interessiert, ob zwischen "Herz::schlagen()" und "Mensch::schlagen()" eine semantische Beziehung besteht oder nicht.

Selbiges gilt für bool Person::istArm() oder Körperteil::istArm() uvm...
Bei derartigen Dingen ein Interface zu konstruieren, damit man Objekte, die die Schnittstelle "istArm()" implementieren per OOP ansprechen kann, lässt sich nur als Designfehler beschreiben. Somit geht "Man abstrahiere nur richtig und schon passt es" und "Selektive Ignoranz" ungeöffnet an den Absender zurück.

Genau das hat mich eben gestoert und stoert mich an JS. Man kann eben jeden Objekttyp als einen Parameter nehmen und behaupten, das er richtig ist, nur weil er zufaellig die richtigen Methoden anbietet. Das der Typ dann doch falsch ist, merkt man erst viel Speater, nachdem man stunden rumgeraetzelt hat wieso das Programm etwas macht, obwohl es etwas anderes machen muesste.

Durch die Beziehung "ist ein" in der Klassenhierrachie kann ich solche Fehler vermeiden, bzw. gar nicht erst aufkommen lassen. Dies wurde z.B. auch in PHP erkannt, indem man Typen fuer Objekte eingefuehrt hat.

Seite 49:

Shade Of Mine schrieb:

Ein C++ Compiler würde Interfaces übrigens meistens wegoptimieren - das nur so zur Anmerken über die Sinnhaftigkeit von Interfaces - denn sie sind nicht auf jeder Ebene im Code vorhanden. Im abstrakten Design des Programmes - zB UML kommen sie vor. In der Zielsprache auch noch - diese wird dann aber nach C übersetzt und schon sind die Interfaces wegoptimiert. Danach das ganze in Assembler und man findet nicht mal mehr die Andeutung von den Interfaces im Code.

Im Asm Code findest du ueberhaupt nichts wieder. Ausser Gotos und bedingten Spruengen. Ist das Konzept von Funktionen dann auch irrelevant?
Hier gibts du Xin aber auch Recht, denn er hat die Behauptung aufgestellt, dass sich die Programme seit den Spruengen im Programm nicht weiter entwickelt haben.

Shade Of Mine schrieb:

Ist nun der JS Code nicht Objekt Orientiert aber das UML Diagramm schon? Genau hier liegen meine Probleme. Ich denke: der Gedanke hinter dem Code ist der selbe - der Code ist so ziemlich 1:1 übertragen worden und deshalb ist er, soweit es die Sprachen erlauben - gleichwertig.

Nein eben nicht. In JS laesst du die Tatsache fallen das X "ist ein" Y ist. Du kannst in JS fuer X irgendwas einsetzen und behaupten "es ist ein Y", das X muss es aber nicht.

Shade Of Mine schrieb:

Die Relation dass Dynamo eine Energiequelle ist, wird entweder durch ein Interface Energiequelle definiert oder dadurch dass Dynamo alle Funktionen einer Energiequelle implementiert. Natürlich ist die JavaScript Lampe nicht Typsicher. Ich kann ihr alles übergeben - zB ein Fahrrad. Aber das ist eben der Punkt an dynamisch typisierten Sprachen: sie sind in dieser Hinsich unsicher und erlauben dadurch mehr dynamik.

Genau das sage ich doch die ganze Zeit. Sie sind unsicher und erlauben mehr Dynamik. Ich weis nur nicht wozu diese Dynamik gut sein soll.

Shade Of Mine schrieb:

Bei C++ Templates mit Constraints hat man dann auch die Beziehung im Code beschrieben. Dann wird die ganze Diskussion noch lustiger - denn dann schreibt man (ich habe keine Ahnung wie die Constraints Syntax mäßig aussehen werden, deshalb lehne ich mal an Java an):

das Beispiel ist aber ziemlich flasch.

Aber Lampe kann nun erkennen ob etwas wirklich eine Energiequelle ist - sprich "Energiequelle implementiert".

Woher will denn das der Compiler wissen? Nach deinem Beispiel muesste der Compiler einen Fehler ausgeben: dynamo does not implements energiequelle. Entweder Typsicherheit, dann braucht man Vererbung. Oder eben nicht.

[otze]

@DEvent

class EnergieQuelle{};//leer
struct Batterie:public Energiequelle
{
    public void foo()
    {...
    }
};

template<class T>
class Elektrogerät
{
     BOOST_STATIC_ASSERT(is_derived<T,EnergieQuelle>::value);
     T member;

     public:
         void bar(){ member.foo();}
};

Jetzt gibt es sogar die Absicherung vom programmierer, dass Batterie eine Energiequelle ist, und somit mit dem Interface übereinstimmt. Vererbung ist, wie wir alle sagten, manchmal sinnvoll, aber nicht zwingend.

wenn ich einen int ähnlichen Objekttyp brauche, werde ich sicher nicht danach schauen, ob es von "Int" abgeleitet ist. mir reicht es, wenn alle Operatoren überladen sind, die ein Int braucht. Was sich wie ein int verhällt, ist ein int.

[@Xin]

komisch in smalltalk ist der typ eines objekts auch ein objekt. und jetzt? gilt deine definition jetzt nur für maschinenkompilierte sprachen? hm moment es gibt auch compiler die aus smalltalk maschinencode generieren
wen interessiert überhaupt maschinencode?
ist ood nicht ein paar ebenen weiter höher?

[minhen]

virtuell Realisticer schrieb:

Shade Of Mine schrieb:

Wenn einem die Argumente ausgehen kommen die Beleidigungen - Schade.

Endet es nicht immer so?

gruss
v R

Wobei der besondere Witz der ist, dass das hier gar nicht der Fall ist. Denn der, der beleidigt hat, ist interessanterweise gar nicht der, dem die Argumente ausgegangen sind. Das sollte einem schon zu denken geben.

Interessant ist auch, dass hier "Ruhe" herrschte während rüdiger und ich diskutiert haben. Und die einzigen offenen Punkte sind jetzt noch, ob Prozesse Objekte sind (was eine nette Seitendiskussion hätte werden können), sowie wie Kapselung in Lisp umgesetzt ist. Damit ist Stroustrups Definition als solche also endügltig geklärt. Aber sobald ich das Thema auf die schwammige, mystische und irgendwie esoterische Definition lenkte, um eben über diese ebenso zu reden, geht's hier rund. Und plötzlich melden sich all jene zurück, die sich bei der ernsthaften Diskussion herausgehalten haben. Wozu das jetzt führt, sieht man ja. Eine interessante Beobachtung ist es dennoch.
Besonders die letzten Äußerungen von Shade of Mine und Mr. N sind da besonders schön. Auch nett ist, wie längst geklärte Sachen wieder ausgegraben werden. Aber dann wiederum ist das nichts neues. Schließlich hat der Thread hier ja nicht wegen vorgebrachten Argumenten und einer vernünftigen Diskussion stolze 55 Seiten erreicht ...

[Undertaker]

minhen schrieb:

Und die einzigen offenen Punkte sind jetzt noch, ob Prozesse Objekte sind (was eine nette Seitendiskussion hätte werden können)

es könnten welche sein.
sie erfüllen ja einige kriterien, die allgemein für objekte gelten. sie können untereinander nachrichten austauschen, sie verstecken ihr innenleben (datenkapselung), sie können auf input dynamisch und unterschiedlich reagieren (polymorphismus). den programmcode eines prozesses könnte man als 'klasse' bezeichnen... usw.

[Tellerrand]

Ich glaube nicht, dass man Kapselung in CLOS ordentlich realisieren kann, wobei ich zugeben muss, dass ich mich nicht sonderlich gut mit CLOS auskenne.
Nur für Kapselung ist Lisp einfach zu mächtig.

Andererseits ist Kapselung öfters keine hundertprozentige Geschichte, Java Reflection bricht z.B. wieder die Kapselung der eigenen Sprache und am Ende folgere ich persönlich, dass Kapselung nur soweit möglich ist wie der Programmierer es zulässt.

Besagt die Kapselung denn, dass man unter garkeinen Umständen an die versteckten Daten und Methoden herankommen darf?
Wie ich finde ist das eine Gratwanderung, und ich sehe Kapselung nur als Einschränkung des Zugriffs, nicht aber als ein Zugriffsverbot, das die Sprache garantieren muss.

[minhen]

Das naive Verständnis von Kapselung ist, gerade wenn man gedanklich in der C++-Welt steckt, sicher die Einschränkung von Sichtbarkeit. Aber wie gezeigt versteht Stroustrup unter Kapselung die Möglichkeit Integritätsbedingungen wahren zu können. Er definiert es also nicht als Einschränkung der Sichtbarkeit sondern funktional. Und dafür hat Doktor Prokt bereits ein Beispiel in Lisp gegeben. Die Spezifikation der Integritätsbedingung lautet in seinem Beispiel, dass x immer größer 0 sein muss.
Dass man sich selbst in C++ mit Tricks sogar zu private-Attributen durchhacken kann, ist eine andere Geschichte. Das liegt, wie du schon ansprichst, durchaus an einer Form der "Mächtigkeit". Aber deshalb würde man auch nicht die grundsätzliche Möglichkeit der Kapselung bei C++ in Frage stellen.

[Xin]

DEvent schrieb:

Seite 46

Xin schrieb:

Selbiges gilt für bool Person::istArm() oder Körperteil::istArm() uvm...
Bei derartigen Dingen ein Interface zu konstruieren, damit man Objekte, die die Schnittstelle "istArm()" implementieren per OOP ansprechen kann, lässt sich nur als Designfehler beschreiben.

Genau das hat mich eben gestoert und stoert mich an JS. Man kann eben jeden Objekttyp als einen Parameter nehmen und behaupten, das er richtig ist, nur weil er zufaellig die richtigen Methoden anbietet. Das der Typ dann doch falsch ist, merkt man erst viel Speater, nachdem man stunden rumgeraetzelt hat wieso das Programm etwas macht, obwohl es etwas anderes machen muesste.

Durch die Beziehung "ist ein" in der Klassenhierrachie kann ich solche Fehler vermeiden, bzw. gar nicht erst aufkommen lassen. Dies wurde z.B. auch in PHP erkannt, indem man Typen fuer Objekte eingefuehrt hat.

Wenn man sich die Ursprünge von JS und PHP ansieht, so sind die noch verwachsener als die von C und das will schon was heißen. C hat als Ursprung "BCPL" und "B", woraus "B mit Strukturen" wurde - daran angelehnt ja auch "C mit Klassen", woraus später C++ wurde.
JavaScript wurde von Netscape entwickelt. Oder besser, man frickelte sich etwas zusammen, um clientseitig etwas programmieren zu können. Kann man sich ja vorstellen, wie das abläuft, oder? Man hat die Idee Funktionalität auf den Client zu legen und so wird ein Trupp von 1-2 Mann von der Browserentwicklung abgetrennt und bekommt den Auftrag etwas zu passendes schreiben, was die Probleme der ersten Idee löst. Formulare am Client überprüfen war damals das Stichwort, wenn ich mich recht entsinne. Keine jahrelange Vorbereitung und Planung, wie man eine Sprache überhaupt sauber aufbaut. Das Ergebnis ist bekannt.

PHP war zu Beginn ein kleines Tool, um zur Laufzeit Dateien zusammenzuschieben - mehr nicht. Kopfzeile, Inhalt, Fusszeile: Fertig war die Webseite.
PHP wurde OpenSource und im Ergebnis haben hunderter "Programmiersprachenexperten" es irgendwie weiterentwickelt, die Betonung liegt auf irgendwie.
Aus sehr viel Frickelei hat sich daraus eine fähige Sprache entwickelt, die allerdings ihren Frickelcharakter nicht mehr verlieren wird und die vom Sprachcharakter fehleranfällig und unsauber ist. Die Sprache kämpft dafür kompatibel mit sich selbst zu bleiben, kann es aber nicht, wenn sie jemals die Kurve bekommen möchte. Aber - und das macht sie so bekannt: Sie ist *die* Sprache in ihrem Bereich, mit der man mit dem geringsten (Lern-)Aufwand eine Homepage zusammenfrickeln kann.

Ich habe 2001 angefangen mich intensiver mit Sprachen zu beschäftigen und darum auch z.B. Bücher von Stroustrup gelesen. Literarisch besonders aufregend kann man den Stroustrups Schreibstil leider nicht grade nennen, spannend ist so ein Buch wirklich nur, wenn man sich für den Inhalt wirklich interessiert.
Seit 6 Jahren plane ich also meine Programmiersprache. 2003 habe ich einen C Compiler geschrieben, um zu gucken, was man mit Compilern eigentlich alles machen kann, um dafür ein besseres Gefühl zu bekommen.
Ich habe im Studium 15 Punkte in Compilerbau und 14 Punkte für den funktionsfähigen Compiler erhalten von zwei unabhängigen Profs. Ich weiß trotz Nachfrage nicht, woran der Abzug beim Compiler lag. Aber ich habe zumindest ein sehr positives Zeugnis zusätzlich dafür erhalten und ein "Sehr Gut" ist auch ohne Plus noch keine Katastrophe. Ich bin in dem Bereich also nicht ganz unfähig.

Dieser Compiler ist inzwischen vollständig in allen Bereichen umgeschrieben und umgebaut worden.
Ich weiß, wie man es richtig macht und inzwischen auch, wie man es noch besser machen kann.
Das kostete 6 Jahre lesen, planen und experimentieren, aber anders geht es nicht. Ich kenne kein Buch, das im Bereich Compilerbau beschreibt, was machbar ist.
Diese Grundlage, die JavaScript und PHP fehlt, sieht man den Sprachen auch an.

Diese Sprachen sind erfolgreich, weil sie eine Nische ohne Konkurrenz besetzen. Browser können nur JavaScript und Webserver sind extremst einfach mit PHP auszurüsten, was die Masse der Hobbyprogrammierer auch bedienen kann. Die Sprachen sind nicht erfolgreich, weil sie gut durchdacht sind.

Wir haben erst 2 von Grund auf konstruierte Sprachen im relevanten Softwaremarkt: Java und C#. Und Java ist als konstruierte Sprache eine große Enttäuschung. Ein gigantischer Aufwand für ein kastriertes C++, dafür mit großer Standardfunktionalität. Darum ist Java erfolgreich. Man ruft 5 Funktionen auf und hat ein einfaches Tool "programmiert". Dafür braucht man auch keine hochqualifizierten Informatiker.
C# hat aus Mängeln von Java sichtlich gelernt - nur leider nicht viel. Java und C# müssen erfolgreich sein. Was für den einen Werbeträger ist, ist für den anderen das Monopol. Beide Sprachen können nicht einfach neue Wege gehen, in der reinen Hoffnung, dass sie akzeptiert werden. Das beschränkt sie in ihrer Weiterentwicklung und das Thema "experimentelle Weiterentwicklung" hätte man berücksichtigen können. Man ist mit beiden Sprachen nicht weit gekommen, denn nicht jeder Schritt ging nach vorne.
Der Rest sind gewachsene Sprachen, C++ liegt irgendwo zwischen gewachsen (C) und (per Cfront geplant) konstruiert und wächst seitdem sehr vorsichtig über ein konservatives Komitee gesteuert.

Lange Rede kurzer Sinn: Wenn man sich mit Programmiersprachen beschäftigt, dann muss man überlegen wo sie herkommen und was sich die Autoren dabei gedacht haben. PHP kann man seine Mängel so gerne verzeihen. Es muss halt mal ein fähiger Mensch hingehen und PHP aufräumen oder eine Sprache anbieten, die die Vorteile von PHP übernimmt und den Mist rauskehrt. JavaScript ist eine Katastrophe, weil man JS nicht so einfach austauschen kann.
Wenn man weiß, wo die Sprache herkommt, identifiziert man die Mängel einfacher und kann sie auch besser akzeptieren. JS oder PHP wurden nicht als OOP Sprachen geplant. Es hat sich eher unverhofft so ergeben. Es ist machbar, aber nicht grade schön. Man hat kein Konzept entwickelt, um möglichst universell Programme lösen zu können, sondern man hat Lösungen für Probleme in eine Sprache eingebaut, aus denen man sich bedienen kann. Interfaces waren für eine schnelle Problemlösung in JS nie erforderlich.
Daraus nun wieder etwas abzuleiten, was als sauber umgesetztes Konzept gelten könnte, wird schwierig.
Und das ist der Punkt.

Am Rande dazu vielleicht noch folgendes: JavaScript heißt eigentlich ECMAScript, JavaScript ist nur der "übliche" Name für ECMAScript.
JavaScript ist nicht kompatibel zu Java.
Eine optische Ähnlichkeit ist gegeben, aber damit hätte es genausogut C++Script heißen können. Von daher reicht das Umbennen von .js nach .java nicht, um JavaScript mit Java zu kompilieren: Man muss es portieren und das ist mit Neuschreiben gleichzusetzen, denn nicht kompatibel meint wirklich komplett inkompatibel, was Ausdrücke angeht, die aufwendiger sind als "a = 1;".
JavaScript und Java sind nicht miteinander verwandt, sondern unabhängig voneinander entstandene Programmiersprachen und abgesehen von einer Ähnlichkeit im Namen, den sie genaugenommen auch nicht haben, haben beide Sprachen absolut gar nichts miteinander zu tun.
Wer JS mit Java kompiliert, möge den Blick auf die Startseite des Forums richten, dort steht beim Java-Forum extra in Fettschrift "kein JavaScript". Die wollen genausowenig JS Fragen beantworten, wie die Leute im C++ Forum Java Fragen sehen wollen.
Darum schrillen bei mir die Alarmglocken für besonders qualifizierte Postings, wenn jemand schreibst, dass er kein Problem hat JavaScript mit Java zu kompilieren.

Shade Of Mine schrieb:

Xin schrieb:

Du kompilierst also JavaScripts mit Java...?

Warum nicht? Was spricht dagegen?

Wieder eine Frage mehr beantwortet.

[Xin]

otze schrieb:

@DEvent

class EnergieQuelle{};//leer
struct Batterie:public Energiequelle
{[...]};

template<class T>
class Elektrogerät
{
     BOOST_STATIC_ASSERT(is_derived<T,EnergieQuelle>::value);
     T member;

     public:
         void bar(){ member.foo();}
};

Jetzt gibt es sogar die Absicherung vom programmierer, dass Batterie eine Energiequelle ist, und somit mit dem Interface übereinstimmt. Vererbung ist, wie wir alle sagten, manchmal sinnvoll, aber nicht zwingend.

wenn ich einen int ähnlichen Objekttyp brauche, werde ich sicher nicht danach schauen, ob es von "Int" abgeleitet ist. mir reicht es, wenn alle Operatoren überladen sind, die ein Int braucht.

Soweit alles richtig.

Und sobald Dein Programm kompiliert ist, hast Du keine Elektrogeräte, die eine EnergieQuelle zum nutzen, sondern Du hast Elektrogerät<Batterie> und Elektrogerät<Atomkraftwerk> usw., die alle nicht miteinander verwandt sind und damit nicht austauschbar sind.
Ein Elektrogerät<Batterie> ist kein Elektrogerät<Atomkraftwerk>, auch wenn sie gleiche Funktionalität bieten, haben sie keine Gemeinsamkeit, die die Programmiersprache interessiert.
Du wirst also jede Funktion für Elektrogerät<Batterie> und Elektrogerät<Atomkraftwerk> redundant schreiben müssen.
Vererbung ist nicht zwingend, aber sinnvoll.

Templates sind Templates und Vererbung ist Vererbung und damit...

otze schrieb:

Was sich wie ein int verhällt, ist ein int.

...ist der Satz auch nur Hall und Rauch.

[@Xin]

ok ich fasse mal zusammen

Xin schrieb:

1: javascript und php sind scheiße
2: ich bin toll
3: shade ist dumm

zu punkt eins sei gesagt, dass sich smalltalk ebenso verhält wie php und java\1: wenn ein objekt eine bestimmte nachricht nicht verarbeitet geht die nachricht halt ins leere. da gibts kein problem mit, das ist auch kein designfehler

Xin schrieb:

Am Rande dazu vielleicht noch folgendes: JavaScript heißt eigentlich ECMAScript, JavaScript ist nur der "übliche" Name für ECMAScript.

eigentlich heißt JavaScript LiveScript. JavaScript ist nur der "übliche" name für LiveScript. ECMAScript heißt nur die standardisierte variante- aber das nur am rande

Xin schrieb:

JavaScript ist nicht kompatibel zu Java.

kras sag bloß

Xin schrieb:

damit hätte es genausogut C++Script heißen können.

dann hätte es aber bei weitem nicht die popularität gewonnen die es heute hat

Xin schrieb:

JavaScript und Java sind nicht miteinander verwandt, sondern unabhängig voneinander entstandene Programmiersprachen und abgesehen von einer Ähnlichkeit im Namen, den sie genaugenommen auch nicht haben, haben beide Sprachen absolut gar nichts miteinander zu tun.
Wer JS mit Java kompiliert, möge den Blick auf die Startseite des Forums richten, dort steht beim Java-Forum extra in Fettschrift "kein JavaScript". Die wollen genausowenig JS Fragen beantworten, wie die Leute im C++ Forum Java Fragen sehen wollen.
Darum schrillen bei mir die Alarmglocken für besonders qualifizierte Postings, wenn jemand schreibst, dass er kein Problem hat JavaScript mit Java zu kompilieren.

oh man jetzt wirds klar, du hast anscheinend gar nicht verstanden was shade damit sagte oder?
egal, hauptsache mal alles schlecht gemacht, alle anderen dumm gemacht, dich selbst als den größten verkauft aber bloß nichts verstehen oder auf andere posts eingehen?

[mal so mal so]

minhen schrieb:

stolze 55 Seiten

in der tat, sowas ist aber auch nur hier möglich. in anderen foren wo ich unterwegs bin wär der thread schon längst im müll gelandet sobald jemand wie Xin anfängt mist zu labern (bzw da der thread ja eigentlich um was ganz anderes ging der entsprechende teil ;))

[ronny]

naja - es ist immer wieder ein tolles armutsbezeugniss für deppen die sich über irrelevante details kloppen wollen

das ist genauso wie die leute die sich klopfen wo spaces bei dem * der pointerdeklaration hinkommen

[Tellerrand]

minhen schrieb:

Das naive Verständnis von Kapselung ist, gerade wenn man gedanklich in der C++-Welt steckt, sicher die Einschränkung von Sichtbarkeit. Aber wie gezeigt versteht Stroustrup unter Kapselung die Möglichkeit Integritätsbedingungen wahren zu können. Er definiert es also nicht als Einschränkung der Sichtbarkeit sondern funktional.

Ich habe eigentlich das selbe Verständnis von Kapselung, nur ich sehe "Sichtbarkeit" als eine Art andere Form der funktionalen Kontrolle an. Anstatt den bisherigen Zugriff zu verändern/überwachen streicht man ihn ganz und schreibt einen neuen.
Man hat also nur diese "einfache" Möglichkeit zur Verfügung.
Am Ende wird man mit beiden Varianten nichts anderes machen, als den Zugriff auf Ojektdaten zu kontrolieren.

minhen schrieb:

Dass man sich selbst in C++ mit Tricks sogar zu private-Attributen durchhacken kann, ist eine andere Geschichte. Das liegt, wie du schon ansprichst, durchaus an einer Form der "Mächtigkeit". Aber deshalb würde man auch nicht die grundsätzliche Möglichkeit der Kapselung bei C++ in Frage stellen.

Ich wollte auf die Frage hinaus, ob es nicht auch in Lisp die Möglichkeit gibt die Kapselung zu durchbrechen. (Bei dem Beispiel von Doktor Prokt)
Und dann stelle ich mir die Frage ab wann Kapselung als solche angenommen wird, also ganz einfach gefragt: "Wie schwer muss es sein die Kapselung zu umgehen, damit man einer Programmiersprache auch Kapselung als Fähigkeit zugesteht?"

[ronny]

kapslung finde ich nicht unbedingt notwendig,

es it eine praktische möglichkeit verantwortungsloses vorgehen zu unterbinden,
wenn man jedoch davon ausgehen kann,
das die nutzer der bibliotheken verantwortungsvoll sind,
ist das ganze nicht mehr sooo wichtig

[minhen]

Tellerrand schrieb:

Und dann stelle ich mir die Frage ab wann Kapselung als solche angenommen wird, also ganz einfach gefragt: "Wie schwer muss es sein die Kapselung zu umgehen, damit man einer Programmiersprache auch Kapselung als Fähigkeit zugesteht?"

Ich würde es da mit der guten alten C-Logik halten. Wenn eine Sprache keine Möglichkeit zur Kapselung bereitstellt, hat sie den vorzeichenlosen Kapselungswert 0. Sobald sie eine Möglichkeit bereitstellt, hat sie einen positiven Wert. Je schwieriger es ist, die Kapselung zu umgehen, desto höher ist der Wert. Das heißt, es kann durchaus Abstufungen von verschieden starken Kapselungen geben. Aber jeder positive Wert evauliert bereits zu true

[Xin]

@Xin (unregistriert) schrieb:

Xin schrieb:

JavaScript und Java sind nicht miteinander verwandt, sondern unabhängig voneinander entstandene Programmiersprachen und abgesehen von einer Ähnlichkeit im Namen, den sie genaugenommen auch nicht haben, haben beide Sprachen absolut gar nichts miteinander zu tun.
Wer JS mit Java kompiliert, möge den Blick auf die Startseite des Forums richten, dort steht beim Java-Forum extra in Fettschrift "kein JavaScript". Die wollen genausowenig JS Fragen beantworten, wie die Leute im C++ Forum Java Fragen sehen wollen.
Darum schrillen bei mir die Alarmglocken für besonders qualifizierte Postings, wenn jemand schreibst, dass er kein Problem hat JavaScript mit Java zu kompilieren.

oh man jetzt wirds klar, du hast anscheinend gar nicht verstanden was shade damit sagte oder?
egal, hauptsache mal alles schlecht gemacht, alle anderen dumm gemacht, dich selbst als den größten verkauft aber bloß nichts verstehen oder auf andere posts eingehen?

Dann will ich mal mit einer einfachen Rückfrage auf Dich eingehen: Wo liegt der Zusammenhang Deiner verbalen Ejakulation zu dem Text, denn Du dazu zitierst?

mal so mal so (unregistriert) schrieb:

in anderen foren wo ich unterwegs bin wär der thread schon längst im müll gelandet sobald jemand wie Xin anfängt mist zu labern

Was mir positiv auffällt ist, dass die Leute, die mich hier beleidigen mehr und mehr Unregistrierte sind, sich also nicht trauen ihre Äußerungen einer eindeutigen Identität zuordnen zu lassen. Das mindert das Risiko dumm darzustehen deutlich, wenn ein halbwegs kompetenter diesen Thread nochmal lesen würde (der allerdings minhen und mich für genauso bekloppt erklären würde, weil wir uns seitenlang diesem Kindergarten widmen.)
Überhaupt "diskutieren" hier fast mehr Unregistrierte als Registrierte, die aber offenbar über 500 Postings im Thread verfolgt haben, um sich mit ähnlichen Lese- und Verständnisschwächen (siehe "@Xin"s-Posting) eine ähnlich beleidigende Meinung bilden zu können, wie sie vorher Registrierte propagierten, die sich nicht mehr beteiligen, weil sie die Hoffnungslosigkeit des Threads natürlich voll durchblickt haben.

Erstaunlich...

Was mich nochmal interessieren würde, ist ob ich nun alle Fragen des unregistrierten Tellerrandes beantworten konnte, da der Punkt, der "meine" == minhens == Stroustrups == Marc++us Definition zum Wanken bringen würde, sich ja nun nicht bestätigt hat.
Ich will ja nicht davon ausgehen, dass ihn das überzeugen konnte, aber es gibt zumindest keine Beleidigungen oder Rückfragen mehr.

Mir würde ein "Ich erwäge inzwischen die Möglichkeit, dass Du, minhen, Stroustrup und Marcus richtig liegen" vollkommen reichen.

[scrub]

Xin schrieb:

Was mir positiv auffällt ist, dass die Leute, die mich hier beleidigen mehr und mehr Unregistrierte sind, sich also nicht trauen ihre Äußerungen einer eindeutigen Identität zuordnen zu lassen.

Du solltest nicht von Dir auf andere schließen. Einige Identitäten können sehr wohl zugeordnet werden- entweder bist Du zu faul oder zu unfähig dafür, aber das ist kein Problem von Unregistrierten.

Und nochmal für Dich: Du unterliegst einer grob falschen Selbsteinschätzung, wenn Du (vor einigen Seiten) meinst, Du hättest Dich hier behauptet. Im Gegenteil! Während Deine Definition immer noch etwa so dasteht wie anfangs, hat "Xin" im Verlauf der folgenden Seiten stark abgebaut.

[Gast]

Xin schrieb:

Das mindert das Risiko dumm darzustehen deutlich, wenn ein halbwegs kompetenter diesen Thread nochmal lesen würde (der allerdings minhen und mich für genauso bekloppt erklären würde, weil wir uns seitenlang diesem Kindergarten widmen.)

Deine Arroganz war bisher eigentlich nur zum Kotzen. Wie auch in diesem Beitrag. Aber spätestens nach deiner Eierschaukelei wie toll du dich doch mit Compilerbau usw. auskennst, bist du in meinen Augen einfach nur ein armer Drops. Sorry.

[Ein ehemaliger Benutzer]

ronny schrieb:

naja - es ist immer wieder ein tolles armutsbezeugniss für deppen die sich über irrelevante details kloppen wollen

das ist genauso wie die leute die sich klopfen wo spaces bei dem * der pointerdeklaration hinkommen

ich hab im laufe der seiten irgendwie aus dem auge verloren, worüber alle eigentlich ursprünglich diskutieren.

[rüdiger]

Xin schrieb:

Was mich nochmal interessieren würde, ist ob ich nun alle Fragen des unregistrierten Tellerrandes beantworten konnte, da der Punkt, der "meine" == minhens == Stroustrups == Marc++us Definition zum Wanken bringen würde, sich ja nun nicht bestätigt hat.

Deine Definition ist nicht die gleiche wie die von Stroustrup oder die von Marcus. Für die zählt zum OOP mehr als nur laufzeit Polymorphie.

Tim schrieb:

Xin schrieb:

Das mindert das Risiko dumm darzustehen deutlich, wenn ein halbwegs kompetenter diesen Thread nochmal lesen würde (der allerdings minhen und mich für genauso bekloppt erklären würde, weil wir uns seitenlang diesem Kindergarten widmen.)

Deine Arroganz war bisher eigentlich nur zum Kotzen. Wie auch in diesem Beitrag. Aber spätestens nach deiner Eierschaukelei wie toll du dich doch mit Compilerbau usw. auskennst, bist du in meinen Augen einfach nur ein armer Drops. Sorry.

Lass ihn doch in seiner Traumwelt leben.

Ist doch logisch. Wir sind alle Kinder, weil er ständig beleidigt, pöbelt und als Argumentation unter anderem seine Eierschaukelei auffährt (ich hab D&E gelesen, obey!!!). ... Allllleeeessssss klaaaaaaaaar ... Mit der Argumentation wird man natürlich auch jeden Aussenstehenden überzeugen.

Ich frage mich eh, wie verschoben das Selbstbild seien muss, wenn man sich in einem Thread wie Xin verhalten hat, um sich am Ende "auf einen Sockel zu stellen" und sich beschwert, das man beleidigt wurde (und dann in dem gleichen Posting eine weitere Beleidigung auszustoßen).