OOP-Wrapper für PB

[X0r]

Hi,
nachdem ich nun diverse OOP Precompiler ausprobiert habe und zum Entschluss gekommen bin, dass SimpleOOP für meine Bedürfnisse wohl am geeignetsten ist, dachte ich mir, dass es wohl Zeit wäre, einen OOP-Wrapper für sämtliche PB-Libs zu schreiben, wobei ich mich zu Beginn hauptsächlich auf die GUI-Lib konzentrieren würde.
Meine Frage wäre nun, wer denn alles Interesse an so einem Wrapper hätte. Eventuell könnte man daraus ja auch ein Community-Projekt machen.

[ts-soft]

Was sollte das für einen Sinn haben? PB Libs wrappen? Du verwaltest also die Eigenschaften
der Libs in Deinem Object, welche PB sowieso verwaltet?

Nur Overhead und zusätzliche Fehlerquelle. Nur der Syntax wegen

Lieber blase ich Luftballons auf, als meine Exe.

[STARGÅTE]

ne ich glaube er will einfach nur nicht mehr:

SetGadgetText(#Gadget, Text$)

machen, sonden:

GadgetID\SetText(Text$)

oder ?

naja ich in kein fan von OOP.

Aber er hat ja gefragt wer Interesse hat ! nicht wer sie nicht hat ^^

[ts-soft]

ne ich glaube er will einfach nur nicht mehr:

SetGadgetText(#Gadget, Text$)

machen, sonden:

GadgetID\SetText(Text$)

oder ?

naja ich in kein fan von OOP.

Aber er hat ja gefragt wer Interesse hat ! nicht wer sie nicht hat ^^

Das alleine ist ja schon Overhead, aber zusätzlich müßte im Object des Gadgets ja auch alle
anderen Werte stehen, die PB intern schon verwaltet, x, y, w, h usw.

OOP ist ja eine feine Sache, aber PB Libs zu wrappen macht keinen sonderlichen Sinn. Es bringt nur Nachteile,
abgesehen von der Syntax.

[inc.]

Alle OOP Frameworks wrappen letztendlich die Systemnative API.
Es wird lediglich der OOP-Komfort dadurch ermöglicht. Und das ist eben dann der Kompromiss, den man eingehen muss.

Ist quasi wie bei GTK -> GTKmm

Ist aber alles Quark, PB ist prozedural, ein OOP Pre-Compiler macht Sinn, um rum zu probieren und zu basteln.
Und wenn du alles gewrappt hast, musst du sodann alles in der IDE mit der "F1" PB Hilfe verbinden, denn die ist für viele unabdingbar.
Was nutzt mir ein Framework, wenn es nicht gut kommentiert, und jederzeit aus dem Code heraus abrufbar ist.

Und, was nützt die ganze Energie wenn es kaum jemand nutzt
Wenn du ein hochqualitatives platformübergreifendes, bereits exisitiernedes OOP-Framework mit allem Komfort haben willst, dann nutze QT.

[X0r]

Code: Alles auswählen

SetGadgetText(#Gadget, Text$)

machen, sonden:

GadgetID\SetText(Text$)

Naja, fast.
Dieses Projekt würde eigentlich nicht nur einfach einen bloßen Wrapper darstellen, da ich mir auch schon Gedanken über ein neues "Event-Handling-System" gemacht hab. Hier mal als Ansatz:

Code: Alles auswählen

...

This\ExitButton\SetEvent(This\Exit_Event())

...

Wäre doch ganz interessant, nich?

Code: Alles auswählen

Nur Overhead und zusätzliche Fehlerquelle. Nur der Syntax wegen :freak: 

Was hat das mit der Syntax zu tun? Meinste, dass ich einen auf coolen OOP-coder machen will?
Du müsstest selber wissen, welche Vorteile einem OOP verschafft. Und speziell bei großen Anwendungen kommt man mit den ganzen Events etc. irgendwann ins Schleudern. Ein ordentliches OOP-Framework dürfte einem da so manches erleichtern...

Ist aber alles Quark, PB ist prozedural, ein OOP Pre-Compiler macht Sinn, um rum zu probieren und zu basteln.

So? Du verschwendest also deine Energie für die Entwicklung eines Precompilers, damit hinterher 2,3 Leute rumprobieren können?
Machst du dich mit dieser Aussage nicht irgendwie selbst fertig?

Und, was nützt die ganze Energie wenn es kaum jemand nutzt

Soweit ich weiß, wurde hier schon etliche Male rumgeheult und rumgebettelt, dass PB endlich mal OOP unterstützen soll. Gut, dieser Wunsch ist zwar nicht in Erfüllung gegangen, aber dafür haben wir ja immerhin die zahlreichen guten Precompiler aus der Community. Fehlen halt noch die entsprechenden Frameworks...

Mit dieser Einstellung wirds mit OOP und PB nie etwas...traurig
Gibt ja noch BlitzMax, nich?

[neotoma]

Als gnadenloser OOP-Vertreter gebe ich Xor recht.
Prozeduale Sprachen sind gerade bei größeren Projekten sehr Feheranfällig.
Die Kapselung in OOP und die wiederversendung von Klassen hilt sich auf das
wesentliche zu konzentrieren.

Die PB-Befehle Wrappen?
Naja OOP ist nicht gerade zum Wrappen gemacht. Umgekehrt wird ein Schuh daraus:
Man kann ein OOP-Framework für die GUI bauen.
Also ähnlich dem MFC von Microsoft.
Das wäre bestimmt spannend. Dadurch bekäme PB-Coding eine besondere note.

SimpleOOP ist wirklich sehr gut. Jeder der sich für OOP in PB interessiert, sollte es ausprobieren.

Mike

[X0r]

Naja OOP ist nicht gerade zum Wrappen gemacht.

Siehe oben. Das Framework würde nicht unbedingt einen reinen Wrapper darstellen. Denn dieser würde z.B. so aussehen:
http://pb-oop.origo.ethz.ch/node/40 (von inc.)
Ausschnitt:

Code: Alles auswählen

Procedure WINDOW.WaitEvent(Timeout.l = 0)
  If Timeout
    ProcedureReturn WaitWindowEvent(Timeout)
  Else
    ProcedureReturn WaitWindowEvent()
  EndIf
EndProcedure

Dass bloßes Wrapping also im Endeffekt sogar völlig sinnfrei wäre, zeigt obiger Code-Ausschnitt.
Also, nochmal: gemeint war kein reiner Wrapper, sondern ein ordentliches, sinnvolles Framework, welches jedoch auf die Funktionalität der PB-GUI-Lib zurückgreift.
Somit würde es neben der Standard-Lib noch eine Version in OOP-Fassung geben.

Hingegen bestünde bei einem Framework, welches direkt auf der WinAPI basiert und nicht mal ansatzweise einen Wrapper der PB-Lib darstellt, die Gefahr, dass sich daraus ein komplett individuelles, von der Standard-Lib weit entferntes Produkt entwickeln und somit Nutzer abschrecken würde.
Versteht ihr?

[ts-soft]

Der Code-Abschnitt enthält überflüssigen Code:

Code: Alles auswählen

Procedure  WINDOW.WaitEvent(Timeout = -1)
  ProcedureReturn WaitWindowEvent(Timeout)
EndProcedure 

macht dasselbe und zeigt das es bloßes wrappen ist!

[X0r]

WTF
Lies dir meinen Beitrag bitte noch einmal durch...
1. ist der Code nicht von mir
und
2. wollte ich nur zeigen, wie ein sinnloser Wrapper aussehen würde, um nochmals zu betonen, dass ich im Gegensatz dazu ein ordentliches Framework vor Augen hatte...

Hast du dir auch mal meinen obigen Beitrag durchgelesen:

Dieses Projekt würde eigentlich nicht nur einfach einen bloßen Wrapper darstellen, da ich mir auch schon Gedanken über ein neues "Event-Handling-System" gemacht hab. Hier mal als Ansatz:

Code: Alles auswählen

...

This\ExitButton\SetEvent(This\Exit_Event())

...

Nennst du das überflüssig?