OOP Precompiler und Konstrukte

[edel]

Tja, dann fehlt nur noch eine IDE, aber eine vorhandene Scite installation anzupassen, dürfte kein Problem sein, denke ich.
Ich habe schon mehrmals Scite.Properties an meine Bedürfnisse angepasst. Auch als ich noch mit PB 3.3 gearbeitet habe, hatte ich eigentlich große Freude mit Scite/Scintilla.
Das wäre (für's erste zumindest) der geringste Aufwand.

Das waere nicht wirklich schwer oder ueberhaupt ein Problem. Notfalls
verpasst man der pb-ide, per dll, nen Klassen-Browser.

*object.THECLASS = New THECLASS

Wie gesagt, ist mir auch noch zu C++ lastig, eher sowas PB mässiges wie

Create *myObject.CLASS

wenn dann waere das aber

Code: Alles auswählen

NewClass myObject.CLASS

Rest folgt ...

[ZeHa]

Naja Variablen macht man so:

Code: Alles auswählen

Otto.Player

und Listen macht man so:

Code: Alles auswählen

NewList Players.Player()

Daher wäre es am besten über:

Code: Alles auswählen

*Otto.Player()

oder

Code: Alles auswählen

NewObject *Otto.Player()

Fraglich ist auch, ob man den Pointer-Stern weiterhin nehmen soll oder ob es Vorteile haben könnte, ihn wegzulassen. Bei Listen hat man auch keinen Stern.

Zum Thema Virtual: Damit wollt ich nicht sagen, daß das Wort dumm ist (und durch "Flexible" oder so besser wird), ich wollt eher sagen, daß es allgemein vielleicht sogar überflüssig ist. Ich weiß, für den Compiler ist es hilfreich, aber es müßte doch eigentlich auch möglich sein, erfolgreich zu compilieren OHNE das Virtual-Schlüsselwort zu kennen. Unter Java überschreibt man einfach ohne Virtual, dafür muß man so 'ne bescheuerte @Override-Annotation setzen. Unter C# gibt's ein richtiges "override"-Keyword. In beiden Fällen muß aber die ORIGINAL-Methode nicht speziell gekennzeichnet werden, außer sie ist abstrakt (und da ist es natürlich wichtig). Nur unter C++ ist es so, daß auch die, die möglicherweise überschrieben werden KÖNNEN, bereits markiert werden müssen durch "virtual" und die, die überschrieben werden MÜSSEN werden mit virtual und "= 0" gekennzeichnet. Da wirkt C# am elegantesten, Original einfach definieren und bei Bedarf überschreiben, aber dann mit einem entsprechenden Keyword.

[edel]

@inc.
Moechtest du hier die Bugs und dergleichen gepostet haben, oder
erst einmal per Pm oder email ?

[inc.]

Du kannst später ohne Probleme selber entscheiden ob du *obj.CLASS oder obj.CLASS nutzen möchtest, denn Variablen denen ein Interface verpasst wurde kann ich einen Wert zuordnen, ...wie du im resutierenden Code sehen kannst

Ob NewClass myObject.CLASS oder NewObject myObject.CLASS ist mir eigentlich wurst, wobei viell. Object hier angebracht ist, da es sich defacto um ein Objekt handelt, andererseits sieht NewClass irgendwie verständlicher aus ... Hmmmmm

ZeHa deinen Vorschlag mit der Klammer-Schreibweise finde ich sehr interessant, denn ... Ich kann dem Konstruktur später Argumente mit auf dem Weg geben.

NewObject myObject.CLASS("Hello Constructor", #True)

ohne Argumente

NewObject myObject.CLASS()

Zum Thema Virtual: Damit wollt ich nicht sagen, daß das Wort dumm ist (und durch "Flexible" oder so besser wird)

Stimme ich dir zu! Dieses Keyword ist lediglich (noch) Platzhalter und damit OOPler es in seinem Sinn verstehen habe ich es in diesem Moment nach bei der C++'schem "Virtual" belassen. "Flexible" gefällt mir auch eher, da es jene Methode eben "flexibel" in seinem Zugriffspointer sein lässt.

Ich weiß, für den Compiler ist es hilfreich, aber es müßte doch eigentlich auch möglich sein, erfolgreich zu compilieren OHNE das Virtual-Schlüsselwort zu kennen.

Wie du an den anderen überladenen Funktionen sehen kannst, ist dies auch ohne möglich, nur dann "siegt" eben die Methode der eigentlichen Klasse und nicht die der geerbten.

Unter C# gibt's ein richtiges "override"-Keyword. In beiden Fällen muß aber die ORIGINAL-Methode nicht speziell gekennzeichnet werden,

... klingt auch sehr logisch ... somit würde jene Methode in ihrem Funktionspointer genutzt werden, die "Override" vor der Methodendeclaration in der Klasse stehen hat.[/code]


@Edel
Vorerst als PM, danke ....

[fsw]

PS: fsw z.B. muss sich viell. eh fragen warum jetzt wieder das gleiche Projekt neu angefangen wird, obwohl er schon sehr weit gekommen ist, ..... nur hat ihn keiner bei seiner Vorleistung durch klare Feedbacks weiter in seinem Projekt unterstützt ... und da hat ihn viell. auch irgendwann mal die Lust verlassen, was dann auch normal ist.
Einfach ihn eine PM senden und ihn fragen, ob er seinen Code vielleicht LGPL'en (o.ä) will, damit man daran ansetzen kann. Sein und Hroudtwolf's Code könnte man in ihren Vorzügen "mergen" um beider Codes Vorteile nutzen zu können.

Danke fuer die Blumen.

Es war wirklich so das ZERO feedback und KEINE unterstuetzung von Fantasie Software software dem LCP ein ende bereitet haben.

Um auf beide punkte einzugeghen (EDIT: Vorsicht! ist ein bissl lang geworden...):

Klar, mein project war closed source, aber im hinterkopf war von anfang an der gedanke wenn ein paar leute ernsthaftes interesse zeigen, das ganze von einem team weiter gecoded werden koennte. Aber der feedback war (ausser ein paar leute es runter laden damit rumspielen and sagen "toll" and das wars.
No feedback what so ever.
Ich hab gewartet das ein paar sagen: "kannste dies noch einbauen?" oder "schau mal hier ist ein bug"...
Aber es kam nichts, niente, nada.
Und glaubt mir da sind bestimmt noch ein paar bugs drin...

Ausser das im englischen forum "oop" von irgendwelchen "besserwissern" total zerpflueckt und niedergemacht wurde, aber so schlimm das Freak ein oder sogar zwei mal die topic schliessen musste ist zum thema oop von PureBasic benutzern nichts passiert.
Das war wirklich nicht die unterstuetzung die ich erhofft hatte.

Der zweite punkt war, das fuer private methoden prototypen erforderlich waren, aber die unter PB3.94 fehlerhaft waren konnte ich an dem project nicht weiterarbeiten. Und da der preprocessor in sich selbst geschrieben war (oop), konnte ich ohne funktionierende prototypen nicht weiter machen.
Als ein bug im englischen forum (durch andere) public gemacht wurde (dlls, prototypen und strings bug) hatte ich mich gleich eingeklinkt und gesagt "ja das muss der bug gleiche bug sein" und Remi auch noch test code geschrieben hatte um den bug anzuzeigen hoffte ich das Fred & Co. dies gleich beseitigen wuerden. Aber die hatten andere sachen zu tun, so war dieser bug leider nicht ganz oben auf ihrer liste.
Was ich ja auch verstehen kann (man kann ja nicht jedem hergelaufenem heini seine gemeldeten bugs beseitigen, als firma man muss ja das "big picture" im auge behalten), aber dieses "total egal" hat mir gezeigt das Fantaisie Software an oop projekten die der community zugute kommen wuerden nicht interessiert war, was ja auch spaeter (ihre einstellung zu oop) auch offiziell erklaert wurde.

Erst als ein paar monate spaeter eine neue beta version von PureBasic raus kam und dieser bug beseitigt wurde war ich in der lage meinen code zu kompilieren, was auf anhieb auch funktionierte.

Aber nach so vielen monaten hatte ich mich schon anderweitig orientiert (programmier technisch of course...) hab tonnen weise mir andere sprachen reingezogen und damit mir ein bild geschafft ueber die "pros" und "cons" von verschiedenen syntaxen und wie einfach oder schwer eine sprache ist.
Hab nicht nur free, oder open source programmier sprachen angeschaut, sondern auch mehrere compiler gekauft.


Unterm strich sieht es so aus:

PureBasic ist nicht mehr meine erste wahl (seit Fruejahr 2000 dabei...).
Sicher all diese extra biblioteken wie Drag&Drop sind schoen und fuer eine programmier sprache schon einzigartig, aber das PureBasic Universe ist mir ohne OOP einfach zu eng.
Seit mehreren wochen (immer wenn ich mal zeit habe) arbeite ich an verschiedenen "parsing techniques" in verschiedenen sprachen und hatte sogar ein altes verlassenes open source project (nicht meins) wieder aufleben lassen und von VC6 auf GCC umgestellt. Der naechste schritt waere den output von BCC32 auf GCC umzustellen (was nicht so einfach ist, weil nicht C++ standard code benutzt wurde, und erzeugt wird... und von den templates ganz zu schweigen...) Mal sehen wie weit ich damit komme.


Meine sourcen herzugeben ist so ne sache.
Ich bin mir sicher dass nach solanger zeit mir sicherlich der magen umdrehen wuerde wenn ich mir den alten code anschauen wuerde (man entwickelt sich ja schliesslich weiter) und es waere mit sicherheit auch ein gutes beispiel wie man es nicht machen sollte (ausser der tokenizer der von Remi stammt...).
Ausserdem habe ich in der PureBasic Lounge mit Wolf ueber sein projekt gesprochen und finde sein ansatz sehr, sehr gut und professionell.
This said, mein code herzugeben wuerde sich IMHO nicht positiv auswirken.

Wenn ich irgendwo mitmache dann hoechst wahrscheinlich mit ihm (was aber noch von verschiedenen Sachen abhaengt...) weil ich denke das es dann mindestenz 2 personen auch benutzen wuerden, und ich muesste dann ja auch mein oben erwaehntes C++ projekt auf eis stellen (C++ code zu erzeugen anstatt PB code reizt mich doch schon...).


Bitte entschuldigt das mein kommentar jetzt so lang geworden ist (von der massiven benutzung von kleinbuchstaben ganz zu schweigen), aber ich dachte es waere gut wenn ihr wuesstet warum LCP auf eis gelegt wurde und der code nicht zur verfuegung steht.

Schoenen tag noch.
fsw

[inc.]

... Ich kann dem Konstruktur später Argumente mit auf dem Weg geben.

NewObject myObject.CLASS("Hello Constructor", #True)

ohne Argumente

NewObject myObject.CLASS()

Problem ist hierbei nur .... wie siehts aus, wenn ein Array von Objekten gebildet werden soll?

Code: Alles auswählen

Dim *myObject.CLASS(30) 
For i = 0 to 30
  NewObject(i) *myObject("Hello Constructor", #True) 
Next i

-> Geht nicht, da Klammer für Konstruktor Parameter reserviert wäre
-> Wäre total Banane und PB unlike.

Code: Alles auswählen

NewObject(30) myObject.CLASS("Hello Constructor", #True)

-> Macht auch wenig Sinn.

Code: Alles auswählen

Dim *myObject.CLASS(30)
For i = 0 to 30
  *myObject(i) = NewObject CLASS("Hello Constructor", #True) 
Next i

-> Aha .... schon besser.
Sicher, damit wäre es wieder etwas C++ nahe, aber mal ehrlich .... man könnte mit leben.

So z.B. beim Erstellen von einem Objekt innerhalb einer Klasse:

Code: Alles auswählen

Class MYCLASS
  MYCLASS()
  Release()

  Private
    String.s
    Long.l
    *Object.OTHERCLASS[32] ; <------ !!!!
EndClass

; // Constructor //
Procedure MYCLASS.MYCLASS()
  For i = 0 to 31
    *this\Object[i] =  NewObject OTHERCLASS() ; Der Verständnis halber hier das "*this" belassen.
  Next i
Procedure


*myObject.MYCLASS = NewObject MYCLASS()

[X0r]

Und nach dem PreCompiler die Anpassung der Libs nicht vergessen. Sonst macht das hier wenig Sinn.

[ZeHa]

Jo natürlich die letztere Variante. Das Array beinhaltet i.d.R. sowieso nur die Pointer und nicht das gesamte Objekt, also ist es schon richtig, das so zu machen.

[inc.]

Und nach dem PreCompiler die Anpassung der Libs nicht vergessen. Sonst macht das hier wenig Sinn.

Das macht hier insofern Sinn, da es eine sprachtechnische Ergänzung ist und unabhängig von einem Framework daherkommt.
Was aber die spätere OOP Only "Reinheit" des Programmierens angeht, da müssten die Libs selber nicht angepasst, aber in Klassen verfasst werden.
Und da ist es egal ob man die PB Library nimmt, nativ die Win32API oder was auch immer.

[X0r]

Das meine ich doch.