OOP Precompiler und Konstrukte

[Rings]

Um dem jämmerlichen Thema mal ne Kick zu geben,
schlage ich vor das ihr hier eure gesammelten werke zu nem
OOP-Konstrukt oder Ansätze von nem PreCompiler hier postet.
Evtl. finden sich genug Leute um einen halbwegs effektiven,
funktionierenden und komfortablen PreCompiler zu schreiben.
Das ganze aber mit nur mit Source hier, so das ALLE daran die
Möglichkeit haben mitzuarbeiten.
Ach, und bitte keine geflame hier. (un)Sinn von OOP
wurde woanders schon oft genug belaabert.

haut rein , macht selber was .

[AND51]

Deine Umfrageoptionen sind nicht gut genug gewählt!
Mein Vorschlag:

• 1. Ja, und ich würde selber mit entwickeln wollen (aktive Zustimmung)
  2. Ja, ich könnte soetwas gut gebrauchen (passive)
  3. Nein, ich/wir benötigen kein OOP

Immer diese Antworten wie "Alles, was oben nicht zutrifft", das bringt doch nix. Ist aussagelos. Sollte ich das etwa ankreuzen, wenn ich für meine Möglichkeit 2 (passiv) stimmen möchte? Woher weißt du dann, was ich sagen will, wenn ich deine 3. Möglichkeit ankreuze?
Außerdem: Wenn du schon JA und NEIN anbietest, was sollte man dann noch anderes dazu sagen wollen? Gibts nichts. Also braucht man auch keine "Alles, was nicht oben zutrifft"-Antwort.

[Rings]

Deine Umfrageoptionen sind nicht gut genug gewählt!

zu spät , kann man nix mehr ändern (iss auch total egal)

[milan1612]

Also ich fänds brauchbar und wär auch bereit, wenn sichs ergibt, aktiv mitzuentwickeln

[ZeHa]

Kleiner Tip, ihr könntet euch den originalen C++ Compiler runterladen (der ja auch nur ein PreCompiler war, ich glaube der war in Perl geschrieben), und den als Vorlage nehmen. Ich denke, der zeigt sehr gut, wie man OOP auf reines PP abbilden kann.

Mich selber würd's auch mal reizen, aber ich glaube, ich würde da nicht dauerhaft dran arbeiten können. Wünsche euch daher trotzdem viel Erfolg, wenn er zuverlässig funktioniert, würde ich mir schon vorstellen können, ihn einzusetzen.


Übrigens habe ich nie verstanden, wie genau man mit den Interface-"Klassen" umgeht. Meine (simple) OOP-Weise unter PB sieht daher ungefähr so aus:

Code: Alles auswählen

; Methoden:
Procedure RenderPlayer(*this.Player)
  DisplayTransparentSprite(*this\SpriteID, GetPlayerX(*this), GetPlayerY(*this))
EndProcedure

; Konstruktoren:
Procedure.l newPlayer(SpriteID.l)
  *this.Player = AllocateMemory(SizeOf(Player))

  *this\SpriteID = SpriteID
  *this\Lives = 3
  *this\Energy = 100
  
  ProcedureReturn *this
EndProcedure

Vererbung mache ich im Moment einfach, indem ich Strukturen erweitere, und gemeinsame Methoden implementiere ich einfach, indem ich als *this-Parameter einfach den Typ des Basis-Objekts angebe.

Wie geht man vor, wenn man Interfaces verwendet?

[AND51]

Deine Umfrageoptionen sind nicht gut genug gewählt!

zu spät , kann man nix mehr ändern (iss auch total egal)

Nun, wenn du es wirklich ernst mit dem Thema meinst, dann hätte ich mir mehr Mühe gegeben!
Sind Kinkerlitzchen, aber allein das fehlende Fragezeichen macht einen uninteressierten Eindruck. -my2cents-

[edel]

Ein sehr grosser Vorteil von PB ist der Debugger. Hier waere ein
einfacher PreCompiler fatal, da nichts mehr stimmen wuerde.
Um hier mehr Leute zu ueberzeugen sollte man sich also darueber
Gedanken machen.

Hier mal ein Beispiel wie es mir gefallen wuerde :

Code: Alles auswählen

Class Test 
  public:  
  Declare Constructor()
  Declare Destructor()
  
  Declare machdas(a.l,b.l)
  
  var.irgendwas
  
  private:
  
  Declare machdies(a.l)
  
  long.l
  string.s
  
EndClass

Procedure Test.Constructor()
  ; Kontruktor
EndProcedure

Procedure Test.Destructor()
  ; Destruktor
EndProcedure

Procedure Test.machdas(*this.test,a.l,b.l)
  ; Methode
EndProcedure

Procedure Test.machdies(*this.test,a.l,b.l)
  ; Methode
EndProcedure


a.test = new test()

Im Prinzip laesst sich das alles auf Strukturen mit Prototypes umbauen,
wobei der Precompiler das Objekt automatisch einfuegt.
Public und private sind nicht wirklich noetig, waeren aber toll
Auch sollte man vorhandene Schluesselwoerter benutzen wie z.B.
Extends usw oder vielleicht sogar Struckture statt Class.

Eine sehr gute Vorlage fuer einen PB - Lexer hat Remi mit seinem
Lexer geliefert. http://www.purebasic.fr/german/viewtopic.php?t=8691
(Hier findet ZeHa auch die Antwort auf seine Frage )

[Rings]

Nun, wenn du es wirklich ernst mit dem Thema meinst, dann hätte ich mir mehr Mühe gegeben!
Sind Kinkerlitzchen, aber allein das fehlende Fragezeichen macht einen uninteressierten Eindruck. -my2cents-

1. Man kann keine umfragen nachträglich ändern.
2. Scheinbar hat das Thema ja bisher noch keiner
einmal konstruktiv aufgenommen.
Oder wo ist dein Vorschlag dazu ?
Wenn du kein interesse (und wohl auch keine Ahnung)
hast, halt dich mal an einen Spruch von Dieter Nuhr.
So ein Post nervt mehr als er nützt und lenkt vom Thema ab.

Ach, und bitte keine geflame hier.

Im übrigen sollte so eine Umfrage eigentlich nur den Sinn haben
um rauszukriegen obs sich wirklich ein paar leute an so
einem Community-Projekt beteiligen wollen.
Eigentlich hätte ein 'Ja' gerreicht.
Denn ansonsten kann man diese Thema OOP mit PB sowieso
direkt wieder schliessen.
Ob das Community-Projekt klappt kann jeder sehen wenn hier in
diesem Thread Vorschläge und Sourcen gepostet werden.
Danke schon mal an alle Konstruktiven achen hier....
Endof OffTopix now.

[ZeHa]

Code: Alles auswählen

Procedure Test.machdas(*this.test,a.l,b.l)
  ; Methode
EndProcedure

a.test = new test()

Hmm, also *this würde ich in der fertigen Version nicht mitübergeben wollen, das kommt irgendwie umständlich. Unter Python kommt auch in jeder Methode der "self"-Pointer mit, aber der Sinn erschließt sich mir nicht so ganz (und es ist auch mehr unnötige Schreibarbeit).

Den Konstruktor würde ich dann eher so aufrufen (das new ist eigentlich überflüssig):

Code: Alles auswählen

a.test(parameter1, parameter2)

Das ist eben das nächste Ding... man muß auch 'ne einheitliche und gut durchdachte Syntax bauen. Und das mit dem Debugger stimmt auch, das wäre sehr wichtig.


EDIT: Noch was, die Syntax sollte sich möglichst stark an PureBasic orientieren. Das heißt, "public:" und "private:" wäre meiner Meinung nach keine gute Idee. Ich weiß, es geht schneller, und es ist unter C++ auch so, aber in PureBasic sollte man aus Konsistenzgründen sowas wie "Private" und "EndPrivate" benutzen.
Darüber hinaus sollte es meiner Meinung nach auch möglich sein, direkt innerhalb der Klassendefinition die Methoden zu implementieren, sodaß man nicht gezwungen ist, Headerfiles anzulegen - obwohl das natürlich auch Vorteile hat. Naja, ihr seht, da kommt ein Haufen Entscheidungen auf euch zu

EDIT EDIT: Ach ja, natürlich müssen dann, um wirklich der PB-Syntax treu zu bleiben, Methoden auch nicht Player.ReduceEnergyBy(5) sondern Player\ReduceEnergyBy(5) geschrieben werden mochte ich zwar noch nie, aber dennoch sollte man halt dabei bleiben.

[DrShrek]

Vieleicht helfen Euch ja auch solche Tutorials

Objektorientierte Programmierung mit ANSI-C:
http://www.mathematik.uni-ulm.de/sai/ws ... nar/neher/