PureBoard

Verfasst: **24.10.2007 09:13**

=> http://pb-lounge.pb-club.de/viewtopic.php?p=50041#50041

Ich hoffe, dass in diesem Fall Kräfte gebündelt werden und das ganze nicht einschläft, weil jedes Projekt zu wenig Leute hat.

cu, guido

Verfasst: **24.10.2007 09:42**

Ein sehr grosser Vorteil von PB ist der Debugger. Hier waere ein
einfacher PreCompiler fatal, da nichts mehr stimmen wuerde.

Möglichkeit wäre z.B. die einzelnen durch den Precompiler hinzugefügten zusätzlichen Passagen mit einem ":" zu einer Zeile bündeln:

z.B:

Code: Alles auswählen

Class MyClass
  MyClass()
  ˜MyClass()

  myMethod1()
  myMethod2()
  
  myLong.l
  myString.s
EndClass

Wird zu

Code: Alles auswählen

Interface iMyClass
  MyClass()
  ˜MyClass()

  myMethod1()
  myMethod2() : EndInterface : Structure sMyClass

  myLong.l
  myString.s
EndStructure

Sodann wäre die Zeilenfolge inhaltlich nicht zerschossen.

Was noch wichtig wäre:

1. Support von Vererbung und damit obligatorischer Polymorphie http://pb-lounge.pb-club.de/viewtopic.php?t=3463
2. Einbindung eines z.B. "OOP-Cutters", der alle im späteren Quellcode ungenutzten Methoden "ausschneidet", somit gibts dann auch kaum den oft genannten Overhead im Executablesize.
3. Da die Herangehensweise mit den Interfaces und der virtuellen Tabelle dem entspricht, wie generell Klassen aufgebaut werden, wäre das von Vorteil, wenn man später PB-Classen via dll's exportieren- , bzw. Klassen aus z.B. C++ dll's importieren möchte.
4. Nutzen von Konstruktoren mit Unterstützen von Parameterübergabe, sowie Destruktoren (oben im Beispiel via dem C++ bekannten "˜" gekennzeichnet.

Die Art von Edel, die Methoden via . von den Klassennamen zu trennen fände ich recht PB-like und gut, macht auch Sinn. Ansonsten gäbe es ja noch den "::" oder einen "|".
Um den Code überschaubar zu halten, würde ich mittlerweile die Methoden mit dem Keyword "Method"/"EndMethod" bezeichnen, ist später auch gut fürs Parsing.
Was den *this\...-Pointer angeht, da wäre ich schmerzfrei, kann auch this\... sein. Der Vorteil an der Nutzung des Keywords "*this\..." wäre, dass sodann kein Konflikt mit globalen Variablen stattfindet. Sicher, innerhalb von Methoden könnte man das sinngemäß trennen, wäre aber doch ein Aufwand.

Rings, das hier ist übrigens kein "Ich will ...." Posting, sondern wenn ich dir helfen kann, dann sehr gerne.

Verfasst: **24.10.2007 11:13**

Mit Parsern habe ich viel Erfahrung. Müsst mir nur noch sagen, wie ich den in die PB-IDE einbauen kann.

Verfasst: **24.10.2007 11:21**

X0r hat geschrieben:Mit Parsern habe ich viel Erfahrung. Müsst mir nur noch sagen, wie ich den in die PB-IDE einbauen kann.

erstmal normal als tool.

An @lle:
Mir isses leider nicht möglich in der pb-lounge auf die entsprechenden
links hin einzuloggen.
kann man denn die quint-essenz der dortigen Post nicht hiermit-reinschreiben ? wär nett.

Verfasst: **24.10.2007 11:23**

>erstmal normal als tool.

Ok, dann sag mir, wie ihr was haben wollt. Dann setz ich mich gleich dran.
Also was alles in was ersetzt werden soll.

Verfasst: **24.10.2007 13:08**

Method und EndMethod finde ich nicht so toll, man kann eine
Methode auch leicht an dem Punkt ausserhalb der Klammern
erkennen. Genauso wie EndPublic usw. Das sieht dann allles
wieder so unsauber aus.

@ZeHa
Pb unterstuetzt keine Module, man muss also seine Klassen
nicht wirklich in einen Header auslagern. "This" als Parameter
zu uebergeben ist Geschmackssache, bei einem Interface wird
es allerdings auch so gemacht.

Vielleicht kann man sich hier noch ein paar Ideen holen :
http://www.freebasic.net/wiki/wikka.php?wakka=KeyPgType

Verfasst: **24.10.2007 14:33**

Rings hat geschrieben:An @lle:
Mir isses leider nicht möglich in der pb-lounge auf die entsprechenden
links hin einzuloggen.
kann man denn die quint-essenz der dortigen Post nicht hiermit-reinschreiben ? wär nett.

Hier ein anderer Link ... die Printversion des Themas ... am besten ganz nach unten scrollen und die letzten Themen lesen:

=> http://pb-lounge.pb-club.de/printview.p ... 8&start=24

Zitat:

Hroudtwolf - Di Okt 23, 2007 8:49 pm

Eigentlich hatte ich die Arbeit aus einigen Gründen am PreCompiler eingestellt.
Da das Thema ja mal wieder so aktuell wie noch nie ist, hab ichs aber wieder aufgenommen.

Allerdings möchte ich das nun nicht mehr alleine machen.
Die Erfahrungen und Kenntnisse anderer sind mir hier sehr wertvoll.

Es kann sich jeder bei mir melden der das mitbringt...

... Spass, Bereitschaft ein EXISTIERENDES Projekt zu unterstützen, sehr gute PureBasic-Kenntnisse, Ahnung von OOP, Teamfähigkeit und Ehrgeiz.

MfG

Wolf

Un in einem weiteren Beitrag schreibt er außerdem:

Hroudtwolf - Mi Okt 24, 2007 12:56 pm

Ja, das ist so ne Sache...
Jeder der Angefangen hat an sowas zu schreiben, möchte seine Arbeit ja nicht umsonst gemacht haben.
Deshalb such ich im moment ja ein paar gute Progger die in dieses "bestehende" Projekt mit einsteigen wollen.
Es besteht ein kompletter Lexer , eine Tokenliste, ein Preparator für Syntax-Erweiterungen, eine komfortable Console-Ausgabe und jede Menge Toolfunktionen.
Ich biete also den Einstieg in ein Projekt bei dem man schon auf F5 drücken kann ^^
Wem das nicht attraktiv genug ist...

In die Syntax des Precompilers hätten nun auch andere Progger Einfluss.
Wer da mit macht, hilft nicht MEINEN PreCompiler zu entwickeln.
Sondern dieses Gemeinschafts-Projekt "PreCompiler".

Verfasst: **24.10.2007 14:35**

Ok, hab mich die letzten 2 Stunden damit beschäftigt, einen PreCompiler zu basteln. Hier das Resultat:

Download: http://www.forgesoft.net/Resources/OOP-Precompiler.zip

Ist natürlich erstmal nur ein Ansatz.

Beispielcode, der kompiliert werden kann:

Code: Alles auswählen



Class Object 
  a.l 
  b.w
  Declare MyObjectProcedure:ProctypeA(a,b)
  Declare DummyProc:ProctypeB(a,b,c)
EndClass



Procedure MyObjectProcedure(a,b) 
  Debug Str(a+b) 
EndProcedure 


Procedure DummyProc(a,b,c) 
  Debug "Summe: "+Str(a+b+c)
EndProcedure 


New MyObject.Object 


MyObject\MyObjectProcedure(1,2) 


MyObject\DummyProc(1,1,0)

Kann man das überhaupt ansatzweise als OOP bezeichnen??

Naja, feedback trotzdem erwünscht.

Achtung: Die Befehle Class, EndClass und New dürfen NIE eingerückt werden! Sie müssen immer am Anfang der Zeile beginnen.
Das gleiche gilt z.B für "MyObject\......".
Wird natürlich später verbessert.

Verfasst: **24.10.2007 14:51**

Schaut schon mal nicht schlecht aus, könntest du bitte den Code mitliefern?

Verfasst: **24.10.2007 14:53**

>Schaut schon mal nicht schlecht aus, könntest du bitte den Code mitliefern?

Noch nicht, erstmal will ich feedback.

PureBoard

OOP Precompiler und Konstrukte