Performancemythen?

Xin

Shade Of Mine schrieb:

Xin schrieb:

Entweder ist es "OO" oder nicht "OO".

klingt sehr vereinfacht. warum muss alles schwarz oder weiß sein? kann nicht etwas grau sein?

Es muss nicht alles schwarz oder weiß sein, natürlich nicht.
"Zur Realisierung haben wir ein bißchen Listen benutzt."
"Meine Frau ist ein bißchen schwanger."
"Es hat grade ein bißchen geklingelt."

Manche Dinge sind entweder so oder so und grade in der Informatik muss man sich darauf einlassen, dass für Grauzonen wenig Platz ist.

Shade Of Mine schrieb:

in c++ habe ich zB programme die teilweise aus reinem C code bestehen - weil es eben alter Code ist, der nach und nach an C++ angepasst wird. Ist jetzt alles OO oder sind nur teile OO oder ist garnichts OO?

Du kannst Probleme in OOP gelöst haben oder nicht, aber ob Du OOP benutzt hast, kann ich Dir daraus nun wirklich nicht sagen.

Shade Of Mine schrieb:

Abgesehen davon, dass es bei Dir auch schmutziges OO zu geben scheint, unterscheidest Du wenigstens zwischen OO-Sprache - sie es nicht gibt - und OO-unterstützende Sprachen. Wir sind uns diesbezüglich also einig.

Was ist schmutziges OOP?

Ich weiß nicht, was schmutziges OOP ist, Du sprichst von reinem OOP, also muss eine Deiner Grauzonen unreines OOP sein.

Shade Of Mine schrieb:

Wenn du JS programmiert hast - dann erklär mir mal fix wieso du dort keine OO hast. Oder hast du sie doch - wenn ja, dann widersprichst du dir ja, weil es in JS keine virtuellen Funktionen gibt. Es gibt kein dynamisches dispatchen.

Ich glaube, es ist ein Posting her, wo ich wiedereinmal betonte, dass man nicht virtual benötigt, um OOP zu programmieren, aber virtual benötigt, um mit C++ unterstützt OOP zu programmieren.

Shade Of Mine schrieb:

Worauf ich hinaus will ist: du ziehst einen Trennstrich den es nicht mehr gibt. Moderne VMs wie Java und .NET erlauben es die Compiletime der Runtime gleichzusetzen. Es gibt keine "das ist statisch" und "das ist dynamisch" Situationen mehr. Denn die Kompilierung findet während der Laufzeit statt und ich kann jederzeit neue Elemente nachladen.

Ich habe noch nie versucht final-Funktionen mit Reflection zu überladen.
Ansonsten sind dort alle Funktionen virtual, also erzwungenes OOP - im Gegensatz zu C++, wo Du erst "virtual" schreiben musst.

Shade of Mine schrieb:

Vererbung und virtuelle Funktion geht problemlos ohne Klassen, aber nicht ohne Klassifizierung.
C hat keine Klassen und man kann trotzdem OOP verwenden.

Vererbung ist für dich also auch Object Cloning?

"Meiner Definition" von Clonen wird eine Kopie angelegt. Solange nur kopiert wird... was bitte soll daran OOP sein?
memcpy ist jetzt nicht als die Basis von OOP verschrieen.
Um einen Algorithmus sich an Objekten orientieren lassen zu können, muss ja auch eine Beziehung zwischen den Objekten bestehen. Das ist bei Multimethoden nicht möglich, denn der einzige Algorithmus, der sich an Objekten orientiert, ist die Compiler, um die entsprechende Methode auszuwählen. Die Relation für den Compiler ist die Tatsache, dass er alle Objekte intern kennzeichnet, als Ableitung von "class Object" oder durch eine VTable. Für den Programmierer bleibt da nichts über, wenn er seinen Part (in C++) nicht über als virtual kenntlich machen würde. Darum sind Multimethoden in C++ mit Objekten ohne virtual auch nicht realisierbar. Die Compilerhersteller können schließlich auch nicht zaubern.

In C++ realisiert man die Beziehungen durch Vererbung. virtual ohne Vererbung ist möglich, aber wenn man sich nur an einem Objekt orientieren kann, dann braucht man kein OOP - es ist sogar dumm OOP dazuzuschalten, weil es statisch schneller geht.

Ohne Beziehung zwischen den Objekten, gibt es keinen Algorithmus, der von der Beziehung über OOP profitieren kann. Daher ist der Vorschlag von Scrub_ leider ein Griff ins Klo:

scrub_ schrieb:

2. Der folgende Codeschnipsel ist OOP, weil abhängig vom Objekt verschiedene Funktionen gerufen werden.
class Katze
{
  public:
    void GibLaut() { std::cout << "Miau"; }
};

class Hund
{
  public:
    void GibLaut() { std::cout << "Wau"; }
};

Katze k;
Hund h;

h.GibLaut();
k.Giblaut();

Der Code ist kein OOP, die Objekte stehen in keinem Verhältnis zu einander, den der Compiler nachvollziehen kann. Die Basisklassifizierung "Tier" ist nur dem Entwickler bekannt. Man kann keinen Algorithmus schreiben, der sich am Objekt orientiert => nicht OOP.

void algorithmus( Tier & tier )
{
  tier.GibLaut();
}

otze hat sich ein wenig kleverer angestellt und stellt nicht die Behauptung auf, es wäre OOP - er fragt nach:

otze schrieb:

Xin schrieb:

Das Objekt ist eine Katze, aber handelt nicht wie eine Katze. Es ist nicht Objektorientiert, weil nach dem Referenztyp (Tier) entschieden wird Tier::GibLaut() aufzurufen, statt Katze::GibLaut().

Das ist aber nur logisch falsch, denn der Referenztyp kann diese Aufgabe ebenso erfüllen.
class Tier
{
  private: 
    string laut;
  public:
    Tier():laut("Hallo"){}
    Tier(const string& laut):laut(laut){}

  void gibLaut(){std::cout<<laut<<"\n";}
};

class Katze: public Tier
{
  public:
    Katze():Tier("Miau"){}
};

int main()
{
  Tier* tier = new Katze();
  tier->GibLaut(); 
}
Das Ergebnis gibt das was wir erwarten. Das objekt verhält sich dem Vertrag entsprechend und gibt uns den geforderten laut zurück. logisch und semantisch korrekt
Ist das nun OOP?

Bevor ich das nun verneine und erkläre, warum ich das verneinen muss, muss ich sagen, dass das bisher definitiv der kreativste Vorschlag ist. Darum werde ich das ausführlicher erklären.
Obwohl die Ausgabe identisch ist, das Programm logisch und semantisch korrekt ist, sind die Programme deswegen nicht semantisch identisch. Es ist wichtig das zu verstehen. Du hast ein anderes Problem gelöst, das zwar die identische Ausgabe produziert, aber trotzdem nicht das Problem ist zu dem Du einen identischen Code abliefern wolltest. Und das Problem, dass Du gelöst hast, benutzt kein OOP.

Du beziehst Dich auf folgende Äußerung:

otze schrieb:

Xin schrieb:

Das Objekt ist eine Katze, aber handelt nicht wie eine Katze. Es ist nicht Objektorientiert, weil nach dem Referenztyp (Tier) entschieden wird Tier::GibLaut() aufzurufen, statt Katze::GibLaut().

Das ist aber nur logisch falsch, denn der Referenztyp kann diese Aufgabe ebenso erfüllen.

Du rufst in beiden Fällen Tier::GibLaut(), die dann Daten aus dem Objekt auf den Bildschirm ausgeben.
Du rufst nicht vom Objekt abhängig unterschiedlichen Funktionen. Dein Algorithmus arbeitet also nicht objekt(-typ) orientiert, er gibt lediglich Daten des Objektes aus.
Du kannst die Daten jederzeit ändern, sie sind nicht typ-spezfisch. Einzelne Katzenobjekte können in Deinem Fall auch "Muuh" oder "Ia" machen. Der Laut ist nicht vom Objekttyp abhängig.
Du hast etwas geschrieben, was einen Laut speichert. Du verwaltest einen Datensatz, aber eben keinen, der objektorientiert angibt, was zu tun ist, sondern einen, der das Objekt beschreibt. Du kannst also Katzen beschreiben, die "Muuh" machen und das ist nicht identisch zum Ursprungsproblem.

Welche Funktionalität in OOP verwendet werden soll, ist dynamisch vom Objekttyp des Objektes abhängig - nicht vom Objekt selbst und auch nicht vom Referenztyp. Alle Katzen miauen und weil das alle Katzen machen, ist das statisch für Katzen festgelegt. Die statische Funktion besitzt aber keinen Namen, die dem Programmierer bekannt ist, er spricht sie über GibLaut an() und OOP sorgt dafür, dass für Katzen-Objekte GibLaut() in der VTable auf die entsprechende Funktion für Katzen verweist.

Wer nun meint, dass ich mich hier um Kopf und Kragen rede (und ich vermute, dass den semantischen Unterschied nicht jeder gleich bemerkt und sich das ganze komplizierter liest als es ist), dem sei das ganze wie folgt verdeutlicht:

Katzen sollen über den Lautsprecher laut geben. Bei Hunden blinkt zusätzlich der Bildschirm, um den User zu erschrecken, bei Pferden wird der Laut auf den Drucker ausgegeben und bei Spinnen, wird er über das Netz versand (Schenkelklopfer, was für ein Wortspiel...).

Für jedes Objekt muss eine vom Objekttyp - nicht vom Objekt - abhängige Funktion gerufen werden und das geschieht in Deinem Beispiel leider nicht, in der virtual Lösung aber schon. Die OOP-Lösung ist also flexibler als Deine Lösung und das macht den semantischen Unterschied aus.

Du bist aber sehr nah dran, objektorientiert zu arbeiten. Du musst Dich nur darauf konzentrieren, Dir Funktionalität zu merken, statt Daten. Wenn man definitiv nie mehr als nur eine Funktion objektorientiert braucht, geht das sogar schneller als virtual zu verwenden, weil man eine Dereferenzierung und eine Addition spart.
Bei mehr als einer Funktion und mehr als 3 Objekten diesen Typs, verbraucht sie allerdings mehr Speicher als die virtual-Lösung.

Sieht nicht ganz so schön aus, weil ich auf virtual verzichte, ist aber semantisch gleichwertig zu meinem Beispiel mit virtual: Die Funktion wird abhängig vom Objekt und nicht vom Referenztyp ausgewählt.

#include "stdio.h"

class Tier
{
  private: 
    static void gibLautImplementation( void ) { printf( "Hallo\n" ); }

  protected:
    Tier( void (* const gibLautImp )(void) ): gibLaut( gibLautImp ) {}

  public:
    Tier():gibLaut( &gibLautImplementation ) {}

    void (* const gibLaut)( void );
};

class Katze : public Tier
{
  private: 
    static void gibLautImplementation( void ) { printf( "Miau\n" ); }

  public:
    Katze() : Tier( &gibLautImplementation ) {}
};

int main( void )
{
  Tier * tier = new Katze();

  tier->gibLaut();
}

---------------------

Ich werde die Diskussion hier nicht beenden, werde mich vereinzelt auch gerne noch teiligen, ich möchte aber zu einem Ende anregen.

Wir diskutieren hier seit 25 Seiten und es unwahrscheinlich, dass hier noch eine Einigung gefunden wird - weniger aus argumentativen Gründen, denn der Tatsache, dass die meisten Menschen, wenn sie sich lange in etwas verbissen haben, auch dann nicht loslassen, wenn sie damit untergehen. Niemand möchte sein Gesicht verlieren.

Meine Frage von Seite 11 hat immernoch keiner beantwortet, ich habe nichtmals gesehen, dass es jemand mit /der/ Standard-Definition versucht hat.

Ich ziehe ein positives Fazit zu diesem Thread.
Ich denke, ich konnte mich über die ganzen Seiten gut behaupten und abgesehen von dem Patzer mit den Multimethoden eine konsistente und schlüssige Grundlage bieten, die von einigen anerkannt wurde und von anderen nicht.
Mich freut, dass "meine" Definition von einigen richtig verstanden wurde und mich freut ebenfalls, dass andere kein Argument vorlegen konnten, um mich an meiner Überzeugung zweifeln zu lassen.
Weiterhin habe ich die Hoffnung, dass diejenigen, die zur Zeit *die* Definition verteidigen, zur Ruhe kommen können, wenn der Thread vorbei ist und sich gelegentlich nochmal kritisch damit auseinandersetzen können.

Dennoch fand ich es sehr lehrreich, denn ich musste meine Definition auf vielerlei Anregungen von euren Anfragen immer wieder prüfen und fand für alles widerspruchsfreie Antworten (ob die jeder verstanden hat - ob aus Verbissenheit zur "üblichen" Definition oder aus meinen mangelnden Fähigkeiten, sie besser zu erklären sei mal dahingestellt).

In diesem Sinne besten Dank an alle Beteiligten, doch mir fehlt etwas die Zeit und kann nicht weiter so viel Zeit in diesen Thread stecken.

"Hindert dich irgendetwas diese "geschlossene" Objektwelt in C++ darzustellen?"

Primitive Datentypen zum Beispiel sind kein Objekt und haben daher mit OO nichts am Hut. Vergleich in Java, primitive Datentypen und Wrapper Klassen (int vs Integer)

Eine geschlossene Objektwelt kann man in C++ zwar realisieren, man hätte dann aber quasi eine neue Sprache entwickelt, es wäre nur ein OO Aufsatz auf eine nicht vollkommen OO Sprache.

Xin

Shade Of Mine schrieb:

Mir ist gerade langweilig, deshalb ein kleines Gedankenspielchen:
class Triangle {
public:
  void draw();
};

class Circle {
public:
  void draw();
};

template<typename Shape>
void foo(Shape* s) {
  s->draw();
}
Das ist ja kein OO Code, weil er statisch ist, nicht wahr?

Korrekt, kein OOP.

Shade Of Mine schrieb:

class Triangle {
  function draw() {}
}
class Circle {
  function draw() {}
}

function foo($s) {
  $s->draw();
}

Ist das OO Code?

Nein, das ist ein Template.
Statt wie C++ Code zu erzeugen, werden sie in PHP direkt interpretiert. Hat $s keine Funktion draw() knallt's halt.

Shade Of Mine schrieb:

Oder was ist damit:

struct Shape {
  void (*draw)();
};

struct Triangle {
  void (*draw)();
};

struct Circle {
  void (*draw)();
};

void foo(void* s) {
  ((Shape*)s)->draw();
}

Das ist OOP, aber grausam. (hatte ich in einem vorherigen Posting auch schon mit char Arrays beschrieben)
Was Du da allerdings beschreibst ist SEHR risikoreich, da Du in C++ nicht garantieren kannst, dass sich die Variable show von Shape an der gleichen Stelle im Objekt ist, wie in Circle oder Triangle.
Darum ist Vererbung wichtig, um das zu garantieren.

Shade Of Mine schrieb:

oder gar komplett ohne Klassen:

function Triangle() {
  this.draw=function(){}
}
function Circle() {
  this.draw=function(){}
}
function foo(s) {
  s.draw();
}

Template.
Edit: Du legst hier übrigens zwei Klassen an, also "ganz ohne Klassen" passt hier nicht ganz.

Shade Of Mine schrieb:

oder komplett ohne member (Nice):

class Triangle {
}
class Circle {
}

show(Tirangle s) {}
show(Circle s) {}

Was das ist, weiß ich auch nicht!? Was soll das werden?
OOP ist es jedenfalls nicht.

otze

ich antworte dir mal in umgekehrter reihenfolge um besser deutlich zu machen, was ich meine:

Du kannst die Daten jederzeit ändern, sie sind nicht typ-spezfisch. Einzelne Katzenobjekte können in Deinem Fall auch "Muuh" oder "Ia" machen. Der Laut ist nicht vom Objekttyp abhängig.
Du hast etwas geschrieben, was einen Laut speichert. Du verwaltest einen Datensatz, aber eben keinen, der objektorientiert angibt, was zu tun ist, sondern einen, der das Objekt beschreibt. Du kannst also Katzen beschreiben, die "Muuh" machen und das ist nicht identisch zum Ursprungsproblem.

Nein, ich kann keine katzen beschreiben die "Muuh" machen, weil die einzige stelle an dem "laut" gesetzt wird, der Konstruktor von Tier ist, und der ist ganz klar von seinem Aufruf und in diesem Konkreten Fall von Katze abhängig. Da Katze aber im konstruktor keinen Laut als argument nimmt sondern eine konstante zeichenkette an den Konstruktor von Tier übergibt, ist es ohne nicht portablen compilerhack nicht möglich, die ausgabe von katze zu ändern. Der Laut ist somit an den Typ von Katze gebunden.

Du rufst in beiden Fällen Tier::GibLaut(), die dann Daten aus dem Objekt auf den Bildschirm ausgeben.
Du rufst nicht vom Objekt abhängig unterschiedlichen Funktionen. Dein Algorithmus arbeitet also nicht objekt(-typ) orientiert, er gibt lediglich Daten des Objektes aus.

Es ist richtig, dass ich nur den Datensatz "laut" ausgebe. Aber was ist der unterschied zwischen einem string und einem funktionszeiger? das sind beides nur datensätze, und alles was auf den string zutrifft, trifft auch auf deinen Funktionszeiger zu(meinetwegen mach bei meinem beispiel den ctor mit dem argument auch protected). Wenn du sagst, dass jeder den string ändern kann, kann auch jeder den Funktionszeiger ändern.

Und wnn du selbst sagst, dass funktionszeiger eigentlich auch nichts anderes als eine selbst gebaute vtable sind, dann haben wirs doch schon. Es besteht kein unterschied zwischen Typabhängigem- und Wertabhängigem Objektverhalten. Virtual ist kein verpflichtendes Kriterium für OOP.

"Statt wie C++ Code zu erzeugen, werden sie in PHP direkt interpretiert. Hat $s keine Funktion draw() knallt's halt."

Die fehlende Typsicherheit hat nichts mit OO zu tun, OO schreibt nicht vor, dass es typsicher sein muss. Es gibt auch OO Sprachen da würde an der Stelle garnichts passieren.
Nur weil es knallen kann und irgendwer ein Objekt "falsch" benutzt ist dies kein Zeichen mangelnder OO.
Ich würde eher kritisieren, dass foo eine globale Methode ist und nicht in einer Klasse, bzw. einem Objekt gekapselt wird.

Xin

otze schrieb:

ich antworte dir mal in umgekehrter reihenfolge um besser deutlich zu machen, was ich meine:

Du kannst die Daten jederzeit ändern, sie sind nicht typ-spezfisch. Einzelne Katzenobjekte können in Deinem Fall auch "Muuh" oder "Ia" machen. Der Laut ist nicht vom Objekttyp abhängig.
Du hast etwas geschrieben, was einen Laut speichert. Du verwaltest einen Datensatz, aber eben keinen, der objektorientiert angibt, was zu tun ist, sondern einen, der das Objekt beschreibt. Du kannst also Katzen beschreiben, die "Muuh" machen und das ist nicht identisch zum Ursprungsproblem.

Nein, ich kann keine katzen beschreiben die "Muuh" machen, weil die einzige stelle an dem "laut" gesetzt wird, der Konstruktor von Tier ist, und der ist ganz klar von seinem Aufruf und in diesem Konkreten Fall von Katze abhängig.

Otzes Code:

class Tier 
{ 
    private: 
        string laut; 
    public: 
        Tier():laut("Hallo"){} 
        Tier(const string& laut):laut(laut){} 

        void gibLaut(){std::cout<<laut<<"\n";} 
}; 
class Katze: public Tier 
{ 
    public: 
        Katze():Tier("Miau"){} 
};

otze schrieb:

Da Katze aber im konstruktor keinen Laut als argument nimmt sondern eine konstante zeichenkette an den Konstruktor von Tier übergibt, ist es ohne nicht portablen compilerhack nicht möglich, die ausgabe von katze zu ändern. Der Laut ist somit an den Typ von Katze gebunden.

Und die Verwendung eben dieses:

int main() 
{ 
  Tier* tier  = new Katze(); 
  tier->laut = "Iaaa Iaaa";
  tier->GibLaut();   
}

Keine Ahnung, warum ich grade nicht "Muuh" schrieb, muss mich bei dem schweren, nicht portablen Compiler-Hack wohl grade vertan haben.

Edit: Ich ziehe das Ia zurück und behalte es für mich...

Du rufst in beiden Fällen Tier::GibLaut(), die dann Daten aus dem Objekt auf den Bildschirm ausgeben.
Du rufst nicht vom Objekt abhängig unterschiedlichen Funktionen. Dein Algorithmus arbeitet also nicht objekt(-typ) orientiert, er gibt lediglich Daten des Objektes aus.

Es ist richtig, dass ich nur den Datensatz "laut" ausgebe. Aber was ist der unterschied zwischen einem string und einem funktionszeiger? das sind beides nur datensätze, und alles was auf den string zutrifft, trifft auch auf deinen Funktionszeiger zu[/quote]
Dann zeig mir mal, wie Du einen String aufrufst, ohne einen Segmentation fault zu bekommen.

otze schrieb:

Wenn du sagst, dass jeder den string ändern kann, kann auch jeder den Funktionszeiger ändern.

Du disqualifizierst Dich soeben für das Lob, dass ich Dir über saubere Beispielcodes gegeben habe.

Du kannst Deinen String const setzen, aber den notwendigen Funktionsruf bekommst Du mit einem beliebigen Datenelement nicht hin. Du bist für OOP gezwungen Funktionszeiger zu speichern.
Meine Lösung ist kein gutes Beispiel, die Funktionszeiger sollten eigentlich statisch hinterlegt werden und nicht im Objekt auftauchen. Dann hat man virtual nachimplementiert. Das war mir als Beispielcode für zwei Klassen allerdings grade zu aufwendig.

Xin

Tellerrand schrieb:

"Statt wie C++ Code zu erzeugen, werden sie in PHP direkt interpretiert. Hat $s keine Funktion draw() knallt's halt."

Die fehlende Typsicherheit hat nichts mit OO zu tun, OO schreibt nicht vor, dass es typsicher sein muss. Es gibt auch OO Sprachen da würde an der Stelle garnichts passieren.
Nur weil es knallen kann und irgendwer ein Objekt "falsch" benutzt ist dies kein Zeichen mangelnder OO.
Ich würde eher kritisieren, dass foo eine globale Methode ist und nicht in einer Klasse, bzw. einem Objekt gekapselt wird.

Ich spreche PHP nicht OO-Fähigkeiten ab.
Ich spreche dem Code OO-Fähigkeiten ab, auf den sich der Satz bezieht.

"Ich spreche dem Code OO-Fähigkeiten ab, auf den sich der Satz bezieht."

Und ich sage, dass nur weil der Code, welcher gepostet wurde, nicht typsicher ist kann man nicht auf mangelnde OO folgern, was du aber anscheinend gemacht hast.
Es ist nunmal auch OO, wenn ich versuche von Objekt XY die Methode Z zu starten, auch wenn es diese garnicht gibt.

Xin

Ich ändere mein Posting nicht, damit ich weiterhin belegen kann, dass wenn ich mich zum Esel mache, ich das wenigstens noch selbst merke

otze schrieb:

Und wnn du selbst sagst, dass funktionszeiger eigentlich auch nichts anderes als eine selbst gebaute vtable sind, dann haben wirs doch schon. Es besteht kein unterschied zwischen Typabhängigem- und Wertabhängigem Objektverhalten. Virtual ist kein verpflichtendes Kriterium für OOP.

Lesen ist auch kein verpflichtendes Kriterium, um an einem Forum teilzunehmen.

Du antwortest auf ein Posting, in (nocheinmal) beschrieben, dass nicht virtual OOP ausmacht, sondern die OOP-Unterstützung ist, die Dir C++ anbietet. Weiterhin findest Du dort eine an Dich gerichtete Erklärung, was genau der Unterschied ist.

Weder Lesen noch virtual sind verpflichtende Kriterien, aber sie helfen ungemein.

Xin

Tellerrand schrieb:

"Ich spreche dem Code OO-Fähigkeiten ab, auf den sich der Satz bezieht."

Und ich sage, dass nur weil der Code, welcher gepostet wurde, nicht typsicher ist kann man nicht auf mangelnde OO folgern, was du aber anscheinend gemacht hast.
Es ist nunmal auch OO, wenn ich versuche von Objekt XY die Methode Z zu starten, auch wenn es diese garnicht gibt.

Nopes, ist es nicht OOP. Erklärungen findest Du ausreichenden Wiederholung in den Postings der letzten 20 Seiten.

Der Durchschnitt

Xin schrieb:

Statt wie C++ Code zu erzeugen, werden sie in PHP direkt interpretiert. Hat $s keine Funktion draw() knallt's halt.

Irgendwie finde ich, dass jetzt nach und nach auch deine Definition von OOP schwammig wird. Jetzt wird anhand des Runtime-Types zur Laufzeit entschieden welche Methode aufgerufen wird, und dir passt es immer noch nicht? Übrigens kann es analog dazu genauso in C++ knallen. Schon einmal die Fehlermeldung "pure virtual function call" bekommen?

Xin schrieb:

Nopes, ist es nicht OOP. Erklärungen findest Du ausreichenden Wiederholung in den Postings der letzten 20 Seiten.

Genau sowas habe ich befürchtet, nur weil Du starke Typisierung als Zwang für OO ansiehst ist das noch lange nicht richtig.
Ich frage mich wie Smalltalk es ohne geschafft hat

Aber das war zu erwarten, wie konnte ich nur glauben, dass jemand seinen OO Horizont über Java und C++ erweitert.

Ich halte mich dann doch lieber raus und schau mir das Ganze weiterhing aus der Ferne an.

TheTester

Tellerrand schrieb:

Ich halte mich dann doch lieber raus und schau mir das Ganze weiterhing aus der Ferne an.

Beschreib doch mal was OO für dich ist.

dv_

Xin schrieb:

Tellerrand schrieb:

"Ich spreche dem Code OO-Fähigkeiten ab, auf den sich der Satz bezieht."

Und ich sage, dass nur weil der Code, welcher gepostet wurde, nicht typsicher ist kann man nicht auf mangelnde OO folgern, was du aber anscheinend gemacht hast.
Es ist nunmal auch OO, wenn ich versuche von Objekt XY die Methode Z zu starten, auch wenn es diese garnicht gibt.

Nopes, ist es nicht OOP. Erklärungen findest Du ausreichenden Wiederholung in den Postings der letzten 20 Seiten.

Objective-C, Python, Lisp, (Das schon erwähnte) Smalltalk machen es so. Geh mal in den jeweiligen IRC-Channels, und erklär der Welt, dass diese Sprachen alle kein OO unterstützen. Auf die Reaktionen bin ich gespannt.
EDIT: Oder noch besser: erleuchte diese Leute hier http://lambda-the-ultimate.org/

Brutus

Xin schrieb:

---------------------

Ich werde die Diskussion hier nicht beenden, werde mich vereinzelt auch gerne noch teiligen, ich möchte aber zu einem Ende anregen.

Wir diskutieren hier seit 25 Seiten und es unwahrscheinlich, dass hier noch eine Einigung gefunden wird - weniger aus argumentativen Gründen, denn der Tatsache, dass die meisten Menschen, wenn sie sich lange in etwas verbissen haben, auch dann nicht loslassen, wenn sie damit untergehen. Niemand möchte sein Gesicht verlieren.

Meine Frage von Seite 11 hat immernoch keiner beantwortet, ich habe nichtmals gesehen, dass es jemand mit /der/ Standard-Definition versucht hat.

Ich ziehe ein positives Fazit zu diesem Thread.
Ich denke, ich konnte mich über die ganzen Seiten gut behaupten und abgesehen von dem Patzer mit den Multimethoden eine konsistente und schlüssige Grundlage bieten, die von einigen anerkannt wurde und von anderen nicht.
Mich freut, dass "meine" Definition von einigen richtig verstanden wurde und mich freut ebenfalls, dass andere kein Argument vorlegen konnten, um mich an meiner Überzeugung zweifeln zu lassen.
Weiterhin habe ich die Hoffnung, dass diejenigen, die zur Zeit *die* Definition verteidigen, zur Ruhe kommen können, wenn der Thread vorbei ist und sich gelegentlich nochmal kritisch damit auseinandersetzen können.

Dennoch fand ich es sehr lehrreich, denn ich musste meine Definition auf vielerlei Anregungen von euren Anfragen immer wieder prüfen und fand für alles widerspruchsfreie Antworten (ob die jeder verstanden hat - ob aus Verbissenheit zur "üblichen" Definition oder aus meinen mangelnden Fähigkeiten, sie besser zu erklären sei mal dahingestellt).

In diesem Sinne besten Dank an alle Beteiligten, doch mir fehlt etwas die Zeit und kann nicht weiter so viel Zeit in diesen Thread stecken.

Oh bitte, wie laecherlich ist das denn.
Jetzt, wo es erst richtig eng fuer dich wird, wo du merkst, dass du mit C++/Java nicht mehr nur die Welt erklaeren kannst, ziehst du den Schwanz ein. Toll ist natuerlich auch die fettgedruckte Bemerkung. Diese rechthaberische Sturrheit. Also irgendwas laeuft bei dir komplett schief.
Unterdrueckt dich vielleicht deine Frau, so dass du dich im Internet dann immer erst austoben musst?

Xin

Der Durchschnitt schrieb:

Xin schrieb:

Statt wie C++ Code zu erzeugen, werden sie in PHP direkt interpretiert. Hat $s keine Funktion draw() knallt's halt.

Irgendwie finde ich, dass jetzt nach und nach auch deine Definition von OOP schwammig wird. Jetzt wird anhand des Runtime-Types zur Laufzeit entschieden welche Methode aufgerufen wird, und dir passt es immer noch nicht?

"Nach und nach", wo Du dich auf ein aktuelles Posting beziehst?

Aber die Sache ist auf den zweiten Blick tatsächlich interessant...
Schließlich wird das Show gerufen, entsprechend des Objektes und das wird zur Laufzeit entschieden. Entsprechendes gilt dann auch für die JS Lösung.

Bleibt die Frage, was hier jetzt gilt.

Die Objekte stehen ja anscheinend nicht miteinander in Beziehung, es findet ja keine Vererbung statt.

Das muss so für PHP natürlich nicht gelten, denn PHP speichert ja die Typinformationen zusätzlich. Die Objekte sind also insoweit miteinander verwand, dass sie eine gemeinsame Basis haben, die die Typinformation beinhaltet.
Das habe ich nicht beachtet, als ich die Antwort schrieb.
Damit gibt es eine gemeinsame Basis, die PHP auswerten kann, es gibt die Typinformation, um Typabhängig die Funktionspointer zu finden.
Damit ist die Vorraussetzung für OOP gegeben.

Es ist tatsächlich OOP, was hier angewandt wird. Allerdings von PHP um das Template auszuführen, nicht vom Programmierer, um ein OOP Problem zu beschreiben.
Aber das ändert ja nichts daran, dass es OOP ist.

Der Durchschnitt schrieb:

Übrigens kann es analog dazu genauso in C++ knallen. Schon einmal die Fehlermeldung "pure virtual function call" bekommen?

Natürlich, aber das ist nur möglich, wenn mam mehrere Sourcecodes hat und bei Erweiterungen von Templates vergißt alle Sourcecodes zu rekompilieren.
Ansonsten würde der Compiler meckern.

Tellerrand schrieb:

Xin schrieb:

Nopes, ist es nicht OOP. Erklärungen findest Du ausreichenden Wiederholung in den Postings der letzten 20 Seiten.

Genau sowas habe ich befürchtet, nur weil Du starke Typisierung als Zwang für OO ansiehst ist das noch lange nicht richtig.

Wurde nie von mir behauptet.

Brutus schrieb:

Xin schrieb:

---------------------

Ich werde die Diskussion hier nicht beenden, werde mich vereinzelt auch gerne noch teiligen, ich möchte aber zu einem Ende anregen.

Oh bitte, wie laecherlich ist das denn.
Jetzt, wo es erst richtig eng fuer dich wird, wo du merkst, dass du mit C++/Java nicht mehr nur die Welt erklaeren kannst, ziehst du den Schwanz ein.

Ich schreibe hier viel und grade ist mir auf die Schnelle bei der PHP Geschichte ein Fehler unterlaufen. Kann passieren, wurde gefunden, kritisiert und widerspricht nicht meiner Definition von OOP. Ich sehe nicht, dass es für mich eng wird.

Auch ziehe ich nicht den Schwanz ein, denn wie Du vielleicht bemerkt hast, möchte ich das Ende der Diskussion anregen, bin aber immernoch hier und beantworte Fragen.

Allerdings spiele ich hier seit 3 Tagen den Erklärbär für's Forum und gelegentlich möchte ich mich auch um andere Dinge kümmern. Was ist daran lächerlich?

Edit: Ich möchte noch hinzufügen, dass hier jeder irgendwelchen Mist posten darf und ich zu (nahezu) jedem (sich in letzter Zeit vorrangig wiederholenden) Posting die passende Erklärung bringen darf. Ich möchte den Zeitaufwand für diesen Thread reduzieren und so übersehe ich schneller mal ein "private" oder ähnliches.
Obwohl hier jeder gestützt durch die Masse Unsinn posten darf, darf ich mir eigentlich keine Fehler erlauben, muss etliche Interpretationsmöglichkeiten voraussehen und gleich mit beschreiben, damit das ganze nicht noch mehr explodiert.
Das ist anstrengend und nur wenige lassen sich darauf ein, darüber mal nachzudenken.
Mir bringt das nicht viel, denn wie ich schon schrieb, wurde bisher nichts vorgebracht, was mich an meiner Definition auch nur zweifeln ließ.
Ich denke, es ist nur verständlich, wenn ich nach sovielen Seiten die Sache nun zurückfahren möchte.

Brutus

Och Hase.
Du bist NICHT der Erklaerbaer.
Denn unter dem hatte ich mir sowas wie 'nen Messias vorgestellt - davon bist du aber noch weit entfernt.
Nimm einfach deine beschissenen Scheuklappen ab. Selbst Jesus, meinetwegen auch Mohammed, waren offener als du und hat keinen Stock im Arsch.

Alternativ darfst du auch einfach gehen.

TheTester schrieb:

Beschreib doch mal was OO für dich ist.

Hehe, ich lasse mich ungern zu einer Definition verlocken.
Es wäre doch viel zu ignorant zu behaupten ich könnte eine Definition in kurzer Zeit hundertprozentig ohne Fehler schreiben.
Da beschränke ich mich lieber auf kleine Beispiele oder Thesen, das ist viel einfacher und es kommt bedeutend weniger murks bei rum.
Insbesondere die Formulierungen sind eine nicht zu unterschätzende Schwierigkeit, Fehlinterpretationen sollte man ja unmöglich machen. Frage mal zum Thema lineare algebra wie die null definiert ist

TheTester

Xin schrieb:

[...]
Die Objekte stehen ja anscheinend nicht miteinander in Beziehung, es findet ja keine Vererbung statt.

Damit Objekte in einer Beziehung zueinander stehen muss keine Vererbungsbeziehung zwischen ihnen bestehen. Es gibt auch noch die einfache Assoziation, Aggregation und Komposition. Das die Sachen nicht das gleiche sind wird auch z.B. durch die Symbolik der UML deutlich.

Aber was anderes, es wäre hilfreich wenn du deine "überarbeitete" Definition in einem vernünftigen Text noch einmal darlegen könntest. Da wie dir ja auch aufgefallen ist, der Thread sehr unübersichtlich wird.

tt

Xin

Tellerrand schrieb:

TheTester schrieb:

Beschreib doch mal was OO für dich ist.

Hehe, ich lasse mich ungern zu einer Definition verlocken.

Warum? Angst, etwas konkretes zu sagen, dass jemand anderer kritisieren könnte?
Keine Sorge, man kritisiert Dich nicht, hier wird man Dich in der Luft zerreißen.

Wenn Du die Deppen ignoriest, hätten wir damit allerdings mal wieder einen konstruktiven Beitrag.

Tellerrand schrieb:

Es wäre doch viel zu ignorant zu behaupten ich könnte eine Definition in kurzer Zeit hundertprozentig ohne Fehler schreiben.
Da beschränke ich mich lieber auf kleine Beispiele oder Thesen, das ist viel einfacher und es kommt bedeutend weniger murks bei rum.

Vor allem, kommt weniger bei rum, weil man sich weniger dem Risiko aussetzt, dass jemand etwas falsifizieren kann.

Tellerrand schrieb:

Insbesondere die Formulierungen sind eine nicht zu unterschätzende Schwierigkeit, Fehlinterpretationen sollte man ja unmöglich machen.

Stimmt - und grade das ist die Herausforderung...

TheTester schrieb:

Xin schrieb:

[...]
Die Objekte stehen ja anscheinend nicht miteinander in Beziehung, es findet ja keine Vererbung statt.

Damit Objekte in einer Beziehung zueinander stehen muss keine Vererbungsbeziehung zwischen ihnen bestehen. Es gibt auch noch die einfache Assoziation, Aggregation und Komposition. Das die Sachen nicht das gleiche sind wird auch z.B. durch die Symbolik der UML deutlich.

Und haben diese Beziehungen etwas mit OOP zu tun?

TheTester schrieb:

Aber was anderes, es wäre hilfreich wenn du deine "überarbeitete" Definition in einem vernünftigen Text noch einmal darlegen könntest. Da wie dir ja auch aufgefallen ist, der Thread sehr unübersichtlich wird.

Vielleicht eine gute Idee. Da diese Definition allerdings bestenfalls Deppenfutter darstellt, damit die was haben, um es in der Luft zu zerreißen, bitte ich dafür um ein wenig Geduld.