PureBoard

Verfasst: **22.10.2007 19:07**

Wenn Du PB nun aber mit OOP machst, und die ganzen Libs umstellst, dann hast Du eine völlig neue Sprache, die mit PB nur noch ein paar Syntax-Regeln gemeinsam hat. Wenn er die dann "PureBasic 5.0" nennt, bitteschön, aber die Kompatibilität zu den alten Versionen ist komplett im Arsch.

Allah akbar .
Auf keinen...
Nur weil die Sprache um ein paar Keywords und Class-Wrapper erweitert würde, wäre es für die P(o)Pler (^^) immer noch die selbe.

Und ich sage auch nicht dauernd "Fred hat gesagt", sondern ich sage "es wäre enorm viel Aufwand", und das kann ich auch sagen, ohne Freds Meinung je gehört zu haben. Aber scheinbar denkst Du hierüber gar nicht nach. Oder meinst Du, die Umstellung schüttelt man mal eben so aus dem Ärmel?

Ja. Und das ist ja auch Freds Sache vor der man ihn nicht beschützen muss. :P
Wenn er durch unsere OOP-Threads und Posts irgendwann die Notwendigkeit und den Kundenwunsch deutlich sieht und nachvollziehen kann, wird er es sicher gerne machen.

MfG

Wolf

Verfasst: **22.10.2007 19:11**

Hroudtwolf hat geschrieben:Nur weil die Sprache um ein paar Keywords und Class-Wrapper erweitert würde, wäre es für die P(o)Pler (^^) immer noch die selbe.

Aufgrund dieser Aussage muß ich leider davon ausgehen, daß Du mein Posting nur zur Hälfte gelesen hast.
Daher zitiere ich mich nochmals selbst:

meine Wenigkeit hat geschrieben:Wenn er dagegen die alten Libs prozedural noch drinläßt, dann sehe ich ein grauenvolles Durcheinander auf uns zukommen, wo Anfänger im Forum fragen stellen und Code posten, in dem OOP-API und prozedurale API wild gemischt werden.

Verfasst: **22.10.2007 19:12**

Ich hab das schon richtig gelesen.
Das verträgt sich aber trotzdem, wie du aus meinen vorhergehenden Posts hättest entnehmen können.

Verfasst: **22.10.2007 19:18**

Ich finde OOP-Unterstützung würde PB echt nicht schaden; der aktuell mögliche Umgang mit Objekten durch Interfaces und Datasection ist doch ein Krampf. Es müssten ja von mir aus nicht mal die Standardbefehle auf OOP umgestellt werden. Soviel von meiner Seite.

Verfasst: **22.10.2007 19:20**

Hroudtwolf hat geschrieben:Ich hab das schon richtig gelesen.
Das verträgt sich aber trotzdem, wie du aus meinen vorhergehenden Posts hättest entnehmen können.

Nicht, wenn alles doppelt vorhanden ist. Wenn nur OOP-Keywords neu sind, aber die Libs alle gleichbleiben, dann ist das kein Problem, wirkt aber inkonsistent. Wenn Du nun aber die Libs alle verdoppelst, einmal als OOP-Variante und einmal als PP-Variante - glaubst Du wirklich, daß das der Zukunft von PB helfen würde?

Verfasst: **22.10.2007 19:24**

Was soll denn daran inkonsistent sein.
In PB hast du doch bereits Objekte. Siehe File-, Window- , Gadget-Lib.
Nur eben dass diese derzeit prozedural angesprochen werden (setgadgetstate (objectid), closefile(objectid)....)
Das einzige was wirklich NUR noch notwändig wäre, wären Class-Wrapper dafür.
Und sowas ist echt kein Hexenwerk.

Zum Bleistift:

Code: Alles auswählen


Class cFile
   hFile.l
   Method Read (sFilename.s)
      this\hFile = ReadFile (#PB_Any , sFilename)
      .....
      .....
      .....
   EndMethod
   .....
   .....
   .....
   .....
EndClass

Das könnte der User sich zur Not auch noch selbst schreiben.
In der Lounge hab ich mal ein Wrapper-Packet für die ganzen PB-OBjLibs hochgeladen.
Mit richtigen OOP-Keywords wäre das noch schöner .

MfG

Wolf

Verfasst: **22.10.2007 19:33**

Ja aber glaubst Du denn, es hilft den Neulingen, wenn sie sowohl

Code: Alles auswählen

DisplayTransparentSprite(#mann, 50, 63)

als auch

Code: Alles auswählen

*mann->DisplayTransparentAt(50, 63)

eingeben können? Verwirrung pur!

Dazu kommt noch, daß manche Libs sogar umdesigned werden müßten. Momentan bauen die doch alle auf Nummern und IDs auf, und es gibt einige Libs, die für ein "knackiges" OOP-Design sogar noch umgebaut werden müßten, weil z.B. bestimmte Werte gar nicht mehr als Parameter übergeben werden müßten, sondern sich die Klasse direkt merken könnte. Dann kommen noch so Dinge wie Konstruktoren dazu, das bietet ja dann letztendlich auch wieder zwei unterschiedliche Möglichkeiten.

Also ich glaube nicht, daß so ein Mischmasch gut für die Sprache wäre. Als Zusatz, ja. Seh ich vollkommen ein, und ich hab auch nix gegen eure PreCompiler und Wrapper-Libs. Aber als offizieller Sprachbestandteil ist es einfach schlecht, wenn es ein "sowohl als auch" gibt, wo ist denn da noch die Linie? Was sagen die Anfänger dazu? Wie viel gemischten Code und noch schlechter designte Software werden wir erleben? Wie viel "PB ist so eine inkonsistente Sprache"-Kommentare wird sich die Community anhören müssen? etc etc etc...

Dann lieber ein PB 5.0 mit reiner OOP-Lib, und weiterhin Legacy-Support für 4.x, ohne Neuentwicklungen.

Verfasst: **22.10.2007 19:38**

Das was du äusserst ist nichts anders als dass du andern Menschen einen gesunden Menschenverstand absprichst.

Ja glaubst du denn dass ein Kaufhauskunde kein Obst mehr kauft, weil er für den selben Preis rote und grüne Apfel kaufen kann ?

Ausserdem reden wir im Kreis.
Du hast offenbar nicht so die Ahnung von OOP und den möglichen Vorzügen die PB dann hätte.
Es wurden hier bereits viele fundierte Meinungen pro und contra OOP in PB angesprochen.
Aber diese Aussage kann ich nicht als fundiert gelten lassen.
Ich hoffe, du überdenkst das nochmal.

MfG

Wolf

Verfasst: **22.10.2007 19:47**

LOL, ich programmiere jeden Tag bei der Arbeit in Java und JAWOHL, ich würde von mir behaupten, daß ich Ahnung von OOP habe. Und zwar nicht gerade wenig.

Und ich habe auch nie gesagt, daß PB mit OOP schlecht wäre, im Gegenteil, auch ich habe mir OOP für PB sehnlichst herbeigewünscht. Als es in 4.0 nicht kam, habe ich verstärkt mit C++ programmiert, weil ich eigentlich fest damit gerechnet hatte.

ICH BIN FÜR OOP, ganz klar. Ich programmiere auch, wenn ich in PB programmiere, grundsätzlich objektorientiert, auch wenn mir die Sprache die nötigen Mittel nicht bereitstellt.

Es geht hier allerdings um das Thema "warum will Fred das nicht einbauen" und "was meint er denn mit den 2 Lagern", und auf dieses Thema hin habe ich ein paar mögliche Gründe genannt, an denen es liegen KÖNNTE. Und ich bin mir auch sehr sicher, daß es daran liegen WIRD. Und einen Sprachmischmasch halte ich nunmal nicht für sehr gelungen.

Wenn, dann muß das konsistent sein, aber die Lib zweimal in der gleichen Sprache zu haben ist blanker Unfug. Wer sich das selbst zusammenbastelt, soll es machen. Allerdings wirkt PB dann nach außen sehr dürftig, weil es zwar OOP unterstützt, die Lib aber prozedural aufgebaut ist. Wenn Fred die Lib komplett umbaut, dann ist es besser, sie NUR noch als OOP-Variante in der Sprache zu haben. Dann wirkt es nach außen perfekt, und es ist schön für die OOP-Gemeinde. Aber dafür ist die Kompatibilität dahin, ähnlich wie bei VB.NET und VB6.0. Diese zwei Möglichkeiten sind aber die einzigen, die sinnvoll und realistisch sind. Offiziell dagegen beides anzubieten, ist in einer Sprache meiner Meinung nach jedoch alles andere als eine gute Idee.

Und der Vergleich mit den Äpfeln hinkt wirklich gewaltig...

Verfasst: **22.10.2007 19:51**

Du hast mir den ganzen Spass an der Diskussion genommen.
Denn seit mindestens 2 Seiten des Threads muss ich mit dir im Kreis labern.

Es ist schade dass du trotz logischer Erklärungen immer noch nicht zu überzeugen bist.

Und, Fred kann selbst entscheiden.
Wir diskuttieren hier weil wir Pro und Contra abwegen und nicht "ob" oder "warum" Fred das derzeit nicht einbaut.
Als Community sind wir die Marktforschung des Herstellers.
Also zählt unsere Meinung.

My 50c.

Auf wiederpost.

PureBoard

OOP in PureBasic die X.