PureBoard

Semikolons haben aber mit OOP nix zu tun

Und daß die Syntax umständlicher erscheint, ist nur die Gewohnheit (und das sage ich aus eigener Erfahrung, ich habe OOP früher gehaßt). Irgendwann wirst Du es total beschissen finden, immer so eine dumme ID als Parameter zu übergeben

Genau. OOP heißt nicht, dass man seine Syntax mit ; { } vollsauen muss! Und Delphi und JavaScript sind keinen schönen Beispiele von OOP.

Achso. Na, ich muss zugeben, dass ich mir unter OOP nur das vorstellen kann, was ich von JavaScript, etc. her kenne.
JavaScript ist, finde ich, ein sehr schönes Beispiel für OOP, denn alle Objekte dort sind so stark gegliedert, wie es sich für OOP gehört: window, math, date, ...

Semikolons haben vielleicht nichts mit OOP zu tun, so gesehen stimmt's schon.
Aber mann kann es auch mit OOP übertreiben:Muss man denn in OOP wirklich alles mit Punkten unterteilen und hinten dran hängen? Kann man es damit denn nicht übertreiben?
Bei diesem Codebeispiel sehe ich nicht wirklich den Vorteil von OOP.

Klar, es ist wirklich ein sehr kurzes und fades Beispiel; aber es ist eines. Der Unterschied bezüglich des Notationsaufwandes scheint mir so marginal, dass sich ein Umstieg innerhalb von PB auf OOP nicht lohnt.

Aber auch bei "längeren" Beispielen bin ich geteilter Meinung: hier kann man sehr schön sehen:
Um ein StringGadget anzusprechen, hangelt man sich in JavaScript/OOP durch die einzelnen hirarchich angeordneten Objekte:
Das Eingabefeld mit dem Namen 'eingabefeld' ist Teil von Formular Nr. 0, dieses ist dem document-Objekt untergeordnet. Und wie über vielem, so steht auch hier das window-Objekt über allem.

In PureBasic hingegen geht das doch nun wirklich bequemer, zumal es in PureBasic (Gott sei Dank) keine Formulare gibt. In PureBasic kann man einzelne Objekte direkt ansprechen, wozu also erst einen "Pfad" davor schreiben?

Andersrum ist natürlich dieser Pfad genau die perfekte Orientierungshilfe. Ich vergleiche das immer mit Dateien: Diese sind auch in einem Pfad gespeichert. Und alle meine Pfade kann ich auswendig.
Wenn man dann noch eine gute IDE wie Delphi 6+ hat (mit Autovervollständigen), dann macht OOP das programmieren wirklich zum Vergnügen!

Dennoch sehe ich keinen Anlass OOP einzuführen, weil es so oder so bestens klappt mit dem Programmieren. Und da in PB PP nun mal Standard ist, warum dann noch einen zweiten Standard einführen?

Ich bin also nicht gegen OOP (außer, es verdrängt PP!). Aber solange es bei mir nicht "klick" macht, kann ich nicht Ja dazu sagen.
Ich würde gern mal ein gutes Beispiel sehen, möglichst eines, dass ich auch verstehe.

Denn hier im Thread wurde bereits geäußert, alles was PP kann, könne OOP auch und noch viel mehr. Was wäre denn eine Situation, wo OOP überlegen ist?

Das ist nicht wirklich OOP. Klar, du hast einen Zugriffsoperater ("."), aber was OOP so besonders macht sind Kapselung, Vererbung und Polymorphie. Wenn du mal raushast, wie mächtig, dieser kleine Punkt ist... uiui. Oder einige andere Sachen.
In PB kannst du eine Variable/ID/Konstante/Liste/Array an eine Funktion übergeben. In anderen Sprachen, übergibst du ganze Objekte oder Container. Das ist, was mir so gut gefällt. Es hat keinen Sinn, OOP in Zweizeilern zu erklären. Oder gar in einem "Hello World". Das ist wohl schon einleuchtender: Python Code

Aber diese JavaScript beispiele sind wieder nur kurze Schnipsel. Es macht keinen Unterschied, ob ich Result = Funktion(ID) mache oder Result = ID.Funktion().
Wirklich genial ist, wenn du eben eine eigene Klasse machst, die in sich geschlossen ist und nach aussen nur über ihre Schnittstellen anzusprechen ist. Deshalb empfehle ich wiedermal (auch wenn ich Java nicht so gern habe): BlueJ
Findet man auch schon günstig bei Ebay und jede Seite war für mich ein Vergnügen!

EDIT:
Zu dem "Pfad" von dem du oben sprichst: sowas nennt man Namespace und ist nützlich und gut. Normalerweise "kann" man in einigen Sprachen mehrere Namensräume (Module/Libs/wie auch immer) zusammenführen. Aber die Gefahr, dass 2 Klassen/Objekte aus unterschiedlichen Klassenlibs die gleiche Eigenschaft, bzw. Methode haben, ist groß. Woher soll der Compiler/Interpreter/JIT dann wissen, um welche Sorte Objekt es sich handelt? Wenn man das vermeiden will, hat man dann am Ende Befehle, die Ellenlang sind. Sowas ist nicht sehr schön. Namespaces sind gut - lasst uns mehr davon nutzen!

AND51 hat geschrieben:Ich würde gern mal ein gutes Beispiel sehen, möglichst eines, dass ich
auch verstehe.

ZeHa erwähnte es bereits:

ZeHa hat geschrieben:Irgendwann wirst Du es total beschissen finden, immer so eine dumme ID als Parameter zu übergeben

im Klartext: Wenn Du beispielsweise eine Datei lesend öffnen willst, so
benötigst Du eine Kanalnummer, die Du entweder selber vergibst
(Filenummer = 0 : ReadFile(Filenummer, ...)) oder Dir mittels #PB_Any
reservieren lässt (Filenummer = ReadFile(#PB_Any, ...)). Diese ID musst Du
dann für alle weiteren Aktionen, die diese Datei betreffen, den
entsprechenden Befehlen übergeben (LOF(Filenummer),
ReadString(Filenummer), CloseFile(Filenummer), etc.)

Mit OOP erzeugst Du einfach ein Datei-Objekt. Dieses Objekt besitzt
automatisch alle dateirelevanten Eigenschaften und Methoden.
Hierbei musst Du also keine ID mehr übergeben, denn das Objekt (hier:
'sw') ist ja eindeutig definiert.

Ein weitere Vorteil: Du kannst nun einfach ein eigenes Objekt definieren,
welches die selben Eigenschaften und Methoden des
StreamWriter-Objektes besitzt (Stichwort: Vererbung) und dieses Objekt
mit Deinen eigenen Eigenschaften und Methoden erweitern oder
bestehende Eigenschaften und Methoden mit Deinen überschreiben.
(beispielsweise, dass automatisch bei jedem WriteLine() automatisch ein
Zeitstempel an den Anfang der Zeile geschrieben wird.)
Grüße ... Kiffi

Hallo!

@ Kiffi:
Dein Beispiel klingt einleuchtend. Wenn ich eine Datei namens "sw" brauche kann ich ein Objekt namens sw anlegen. Andersrum geht es aber doch auch per ID. Das ist natürlich ein ewiger Streitpunkt. Der eine kann's so besser, der andere so. Der eine ist Links- der andere Rechtshänder; da könnt man sich auch ewig streiten, was besser ist.

Trotzdem ist deine Variante auf seine weise Vorteilhaft, allein schon von der Notation her. Und in gewisser Hinsicht auch übersichtlich.
Wenn man noch ein "with" einbaut (JS), könnte man nochmals den Code verkürzen und übersichtlicher machen.

@ bembulak:
> was OOP so besonders macht sind Kapselung, Vererbung und Polymorphie
Ja, davon habe ich auch schon gehört, man soll in OOP seine eigenen Objekte und Methoden erstellen können. Zugegeben weiß ich (noch) nicht so wirklich was das ist und was man damit machen kann (außer dem, was Kiffi erzählte).
Klingt praktisch, ist das in PP dasselbe wie Macros?

> sowas nennt man Namespace
Stimmt, das Stichwort fiel mir erst bei Klick auf "Absenden" ein. Namespaces kenne ich von Perl her. Wirklich praktisch!

Also ganz ganz wichtig ist, zu begreifen, daß OOP im Wesentlichen nicht gleichzusetzen mit einer bestimmten Syntax ist. Das ist wirklich wichtig, OOP bedeutet nicht "ich benutze einen Punkt", sondern OOP ist eine Art und Weise, wie man mit seinen Daten umgeht und wie man sie organisiert. Da steckt viel mehr dahinter, als einfach nur eine andere Syntax zu verwenden.

Deshalb ist es ja auch möglich, in PB mit den normalen Mitteln OOP-artig zu programmieren. Obwohl die Syntax das nicht direkt ermöglicht. Man könnte sagen, "OOP fängt im Kopf an". Daß einige Sprachen die OOP eben so super unterstützen, daß sie speziell drauf ausgelegt sind, ist natürlich super, und da gehört dann auch eine entsprechende Syntax dazu. Aber im Grunde ist das erstmal zweitrangig, das wichtigste ist das Konzept von OOP.

Klingt praktisch, ist das in PP dasselbe wie Macros?

Nein, das ist etwas völlig anderes. Es ist aber nicht leicht, das zu erklären, ich versuch es trotzdem mal. Stell Dir vor, Du schreibst ein Spiel. Dann erstellst Du verschiedene Objekte, z.B. einen Spieler, eine Map, ein Item, eine Inventarliste, usw., und all diese Objekte haben eigene Methoden, sprich, eigene Funktionen, die nur auf dieses Objekt zutreffen. Zum Beispiel kann der Spieler sterben, Energie verlieren, ein Leben bekommen, laufen, springen, sich verwandeln, die Map kann man laden, anzeigen, erweitern, usw., und genau diese Methoden sind eng mit dem Objekt verknüpft. Das heißt, Du rufst dann map.load() auf und player.kill(), und nicht LoadMap(#number) und KillPlayer(#id). Das mag jetzt wieder rein nach Syntax aussehen, ist es aber nicht. Du kannst nämlich von jedem Objekt-Typ (Klasse) weitere, neue Typen ableiten. Zum Beispiel leitest Du den Player von einem "Wesen" ab, und von diesem Wesen leitest Du aber auch sämtliche Gegner ab. Jetzt haben Spieler und Gegner zum Teil natürlich unterschiedliche Eigenschaften und Methoden, aber im Kern haben sie auch viel gemeinsam. Und hierbei hast Du jetzt z.B. auch wieder den Vorteil, daß Du eine Liste von "Wesen" haben kannst, in der Du sowohl Spieler als auch Gegner speichern kannst, und dann über die gesamte Liste iterieren kannst und alle sterben lassen kannst, weil alle ein "Wesen" sind, das sterben kann. Das ist mal nur eines von vielen Beispielen. Und auch das ist in PB möglich, allerdings längst nicht so komfortabel und sicher wie in einer Sprache, die OOP direkt unterstützt.

Aber da könnte man ewige Aufsätze drüber schreiben. Wichtig ist, Du definierst Objekte, die haben eigene Variablen und eigene Methoden, und kümmern sich sozusagen "selbst" um ihr Befinden. Diese Objekte kannst Du dann wiederum miteinander verknüpfen. Aber Du hast alles schön klar gekapselt und strukturiert.

Wichtig: Erst, wenn Du einmal wirklich verstanden hast, was OOP ist, und es auch schon eingesetzt hast, wirst Du erst merken, wie gut es tatsächlich ist. Bevor dies passiert, wirst Du ewig dran rummeckern und sagen "brauch ich doch nicht". Ging mir auch so. Ähnlich wie beim Handy, "brauch ich nicht" hab ich da ewig gesagt. Bis ich eins hatte und wenn ich es heute abgeben müßte...

AND51 hat geschrieben:Klingt praktisch, ist das in PP dasselbe wie Macros?

Mh, das ist schwer zu vergleichen, weil es einfach generell eine andere Art der Programmierung ist, und auch der Scope dieser Methoden sich immer verändert/je nach Methode/Objekt/Kapselung.

Schau dir mal Java an, und versuch es zu verstehen- vielleicht bekommst du dann eher ein Gefühl dafür, was OOP ist und was nicht. Und was es bedeutet- JavaScript ist nicht wirkliches OOP, Python und Java da schon eher. Außerdem kann man erst, wenn man die Denkweise durchschaut hat merken, was es für Vorteile mit sich bringt.

Ich bin zwar kein 100%iger VErfechter von OOP, nur weiß ich, dass es mir eigentlich gute Möglichkeiten bietet. Da wir af der Arbeit aber an PP festhängen, kann ich praktisch noch nicht so viel damit machen.

Aber wie gesagt, man muss das System verstehen- die Denkweisen, die einem diese Struktur das eröffnen kann, sind teilweise echt mächtig!

Danke euch beiden, jetzt hab ich schon eher begriffen, was OOP bedeutet. Dass OOP nicht heißt "ich benutz nen Punkt" (geiler Satz ), das wusst ich auch schon vorher.
Eure Ausführungen haben mir sehr geholfen.

Im prinzip ist OOP von der Logik sogar einfacher als Prozedurale Sprachen:

An einem Auto soll z.B. die Tür geöffnet werden.

OOP:
- Auto öffne die Tür.

Prozedural:
- Ein Türeöffnen soll auf das Auto angewendet werden.



Ich verstehe eh dieses ganze Hick hack nicht. Jeder so wie er will, aber als Grund zu nennen, dass man es vermeiden will, dass sich das PB Lager in Prozedural oder OOP spalten könnte und deswegen kein OOP integriert wird ist unsinn.
Derjenige der OOP sodann "nativ" anwenden will spaltet sich eh früher oder später ab, und dann wäre es doch besser, wenn jener (wenn überhaupt) in ein anderes Lager der selben Community wechselt, als einen Wechsel zu einer anderen Sprache zu vollziehen.


PS: Es wurde hier im Thread SDL als Referenz für den Sinn des Proceduralen Sprachankonzeptes im Beispiel von C genannt.

SDL ist in prozeduralem C verfasst, um eine weitestgehende Portierbarkeit zu gewährleisten, und das ist ja genau der Sinn jener Open-Platform APIs (SDL, OpenAl, .... etc etc).

Anderes Beispiel: die meisten GUI Frameworks sind für C++ (objektorientiert) ausgelegt, egal ob wxWidgets, Ultimate++ oder weiss der Geier.


Wir können es drehen und wenden wie wir wollen. OOP gibts nur dann, wenn Fred es selber für sich als richtig ansieht. Habe mir gestern mal Freebasic angesehen und mich ein wenig in deren Foren bewegt. Sehr interessant, dort wird um eine OOP integration nicht so ein Wind gemacht.