Seite 1 von 9

OOP Precompiler und Konstrukte

Verfasst: 23.10.2007 19:44
von 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 .

Verfasst: 23.10.2007 19:54
von 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.

Verfasst: 23.10.2007 20:27
von Rings
AND51 hat geschrieben:Deine Umfrageoptionen sind nicht gut genug gewählt!
zu spät , kann man nix mehr ändern (iss auch total egal)

Verfasst: 23.10.2007 20:34
von milan1612
Also ich fänds brauchbar und wär auch bereit, wenn sichs ergibt, aktiv mitzuentwickeln :allright:

Verfasst: 23.10.2007 21:04
von 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?

Verfasst: 23.10.2007 21:19
von AND51
Rings hat geschrieben:
AND51 hat geschrieben: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-

Verfasst: 23.10.2007 23:49
von 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 :D
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 ;))

Verfasst: 24.10.2007 08:44
von Rings
AND51 hat geschrieben: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.
Rings hat geschrieben: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.

Verfasst: 24.10.2007 09:00
von ZeHa
edel hat geschrieben:

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.

Verfasst: 24.10.2007 09:09
von DrShrek
Vieleicht helfen Euch ja auch solche Tutorials

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