OOP Precompiler und Konstrukte

[inc.]

Eine Methodendeklaration in der Klassenstruktur kann imho übersichtlicher ablaufen. z.B.:

Code: Alles auswählen

Class MyClass 
  Public
    Set(string.s, long.l) 
    Get.s() 
  
  Private
    myLong.l 
    myString.s 
EndClass 

So bleibt es PureBasic like, also wie man es von den Interfaces her kennt, bis natürlich auf Public & Private.

Die Methodendefinitionen sollten klar der Klasse zugeordnet sein, wo wie von Edel als Beispiel gezeigt. Also Klasse.Methode() :

Code: Alles auswählen

Method MyClass.Set(string.s, long.l)
  *this\myLong = long
  *this\myString = string +" hat die Nummer "+str(*this\myLong)
EndMethod

Method.s MyClass.Get(*return=#Null)
  If *return
    PokeS(*return, *this\myString)
  EndIF
  MethodReturn *this\myString
EndMethod

Durch das Keyword "Method" hat man sodann die Möglichkeit der Übersicht halber Methoden von Prozeduren zu trennen und natürlich ists für dich so einfacher zu "parsen".

Anwendung:

Code: Alles auswählen

*obj.MyClass = MyClass()   ; Wozu New? Innerhalb des Konstruktors wird der Speicher des Objekts eh Heapallocated
*obj\Set("Beispiel", 9)
Debug *obj\Get()
;  ... oder ... :
str.s = Space(128)
*obj\Get(@str)
debug str

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\......".

Code: Alles auswählen

Zeile.s = LTrim(Zeile.s)

Aber das weisst da ja.

[X0r]

Nö weiß ich nicht. Ist ja mal wieder ein Luxus.

[inc.]

Nö weiß ich nicht. Ist ja mal wieder ein Luxus.

Was genau ?

EDIT: Misverständnis

[X0r]

LTrim

[edel]

@X0r

In deinem Beispiel fehlt ja der Zusammenhang wischen
Procedure und der eigentliche Klasse. Wie soll das gehen
wenn man mehrere Klassen in den Code schreibt ? Und
was zum Teufel ist "ProctypeA" ?

[Rings]

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

Danke. habsgelesen.
wär natürlich enorm von vorteil wenn Hroudtwolf seinen Code
hier mit reinfliessen würde lassen.

Ich hoffe das er den Vorteil sieht wenn man das als
Gemeinschaftsprojekt mit offenen Quellen macht.

[Hroudtwolf]

Sorry,

Aber ich halte nichts von Scheunentor offenen Projekten.
Wenn man da nicht nen Deckel drauf hält, hat übermorgen plötzlich jeder D... äh, X...äh, F... äh Noob einen Precompiler geschrieben.

Wie ich bereits geschrieben habe, teile ich mir gern die Arbeit mit andern und möchte mein ehemaliges Privat-Projekt auch gern als Team-Projekt ansehen.
Doch, einfach meine Source posten, mach ich nicht.

Hoffe du hast Verständnis.

MfG

Wolf

[Rings]

Sorry,

Aber ich halte nichts von Scheunentor offenen Projekten.
Wenn man da nicht nen Deckel drauf hält, hat übermorgen plötzlich jeder D... äh, X...äh, F... äh Noob einen Precompiler geschrieben.

Wie ich bereits geschrieben habe, teile ich mir gern die Arbeit mit andern und möchte mein ehemaliges Privat-Projekt auch gern als Team-Projekt ansehen.
Doch, einfach meine Source posten, mach ich nicht.

Hoffe du hast Verständnis.

MfG

Wolf

Ich respektiere deine Meinung dazu.
An alle anderen:
Einem solchen Projekt jenseits von Opensource
(man verliert deswegen nicht sein (C)opyright ) gebe ich
allerdings kein langes Leben, siehe Problematik Userlibs und
versch. PB-Versionen.
Nur ein offener Code bei diesem Projekt ist portable und pflegbar.

Ich selbst habe damit hier bei PB gute Erfahrung gemacht.
(deswegen mache ich selbst aber auch noch Closed-Projekte)

[ZeHa]

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.

Klar sieht es unsauber aus, aber "ProcedureReturn" und solche ewigen Rattenschwänze sahen auch schon immer unsauber aus. Wichtiger ist meiner Meinung nach, daß man sich 100% an die bisherige PB-Syntax anlehnt und überlegt, wie es Fred wohl genannt hätte. Statt Public und EndPublic kann man natürlich auch direkt eine PublicMethod und eine PrivateMethod einführen, wäre auch 'ne Möglichkeit, ist dann mehr Java-like.

Auf der anderen Seite ist es aber in C++ soweit ich weiß als normales Label realisiert, d.h. man könnte natürlich auch Public: und Private: machen, mit Doppelpunkt, aber dann bitte mit großem "P" jeweils.

Auch "new" darf nicht klein sein, aber wie gesagt, das könnte man auch ganz weglassen. Eine Variable definiert man ja über Variablenname.Typ, dann könnte man Variablenname.Klasse(Parameter) als Konstruktor benutzen. Für "delete" müßte man dann sich aber auch wieder was überlegen.

Also darauf müßte man wirklich höchste Priorität legen, meiner Meinung nach. Wenn das Teil wirklich dicke als "quasi-offizielles" OOP-Package daherkommen soll, dann muß das in sich wirklich super durchdacht und strukturiert sein, sonst wird es immer wie ein billiges "von irgend'nem User in der Mittagspause entwickeltes" Tool wirken

[ZeHa]

Einem solchen Projekt jenseits von Opensource
(man verliert deswegen nicht sein (C)opyright ) gebe ich
allerdings kein langes Leben, siehe Problematik Userlibs und
versch. PB-Versionen.
Nur ein offener Code bei diesem Projekt ist portable und pflegbar.

Am besten wäre es wohl, wenn es irgendwo eingecheckt wird, wo es sich jeder auschecken kann, aber eben nicht jeder einfach so einchecken kann, sondern es ein kleines Kern-Gremium gibt (das natürlich aus fortgeschrittenen Programmierern bestehen sollte), welches darüber entscheidet, was reinkommt, und was nicht.