PureBoard

Bis vor ein/zwei Wochen habe ich auch noch mit 4.02 gearbeitet.
Als es aber dann um individuelles Keyword-highlightnig und Faltungen ging, war der Umstieg klar.

Version 1.0r58 für Windows & Linux
http://pb-oop.origo.ethz.ch/download

Changelog:
http://pb-oop.origo.ethz.ch/wiki/changelog

EDIT:

Da mir manche Keywords zu lang sind, hab ich nämlich z.B. Procedure und EndProcedure durch "Proc" und "EndProc" ersetzt, und ProcedureReturn durch ein simples "Ret". Aber das geht jetzt nicht in Verbindung mit Deinem Compiler

Solange das Macros sind, welche nur einem Wort, also keinem Code entsprechen, geht das jetzt.

Beispiel Das geht auch mit allen anderen- und natürlich auch PB-Keywords, also nicht nur mit den OOP-Keywords.

Mir ist grad aufgefallen, daß ich gezwungen bin, erst alle Methoden und danach die Variablen zu deklarieren. Mache ich es andersrum, erhalte ich einen Garbage-To-The-End-Of-Line-Fehler. Wäre noch ganz schick, wenn Du das beheben könntest


EDIT: Und es gibt noch Probleme bei zyklischen Abhängigkeiten. Ich weiß nur nicht, wie leicht sowas behebbar ist. Jedenfalls wenn ich zwei Dateien hab, die gegenseitig ihre Klassen benutzen (und sich über XIncludeFile einbinden), dann kann temporär die eine Datei nicht erstellt werden. Aber es kann sein, daß das bei mir in der Praxis anders aussehen wird (hängt ja auch davon ab, wie man sein Projekt strukturiert), ich hab jetzt nur mal ein bißchen rumprobiert mit ein paar Testklassen und da ist mir das eben aufgefallen.

Und Funktionen überladen funktioniert leider auch nicht, wenn ich in einer abgeleiteten Klasse nochmal die gleiche Funktion deklariere, wird trotzdem die von der Superklasse aufgerufen. Das ist natürlich ziemlich unpraktisch... ich hoffe daß das für die nächste Version vorgesehen ist oder muß man das irgendwie explizit deklarieren? Wenn ja, wie?

EDIT: Hab's rausgefunden über Flex also... okay, muß man wissen
Wäre schön, wenn wenigstens eine Warnung kommen würde, wenn man in einer abgeleiteten Klasse eine Methode deklariert, die in der Superklasse bereits existiert, aber nicht als Flex deklariert ist.

Muß aber noch ein bißchen Kritik loswerden, und zwar find ich es ziemlich unpassend daß der Konstruktor so heißen muß wie die Klasse, der Destruktor heißt aber Release(). Erstens gibt's sicherlich viele Klassen, bei denen man eine Release()-Methode für andere Zwecke hätte, und zweitens ist das insgesamt nicht besonders konsistent. Eine weitaus bessere Lösung wäre meiner Meinung nach Constructor() und Destructor(), oder NewObject() und DeleteObject() oder sonst irgendwas, aber KlassenName() und Release() ist meiner Meinung nach keine schöne Lösung.

Und noch was... das mit den PB-Keywords klappt bei mir immer noch nicht :/ -> hab's grad gemerkt, die EXE in Deiner r60-Version ist nicht die aktuelle, nur die in Deiner Standalone-Version. Hab sie ersetzt

EDIT: Und es gibt noch Probleme bei zyklischen Abhängigkeiten. Ich weiß nur nicht, wie leicht sowas behebbar ist. Jedenfalls wenn ich zwei Dateien hab, die gegenseitig ihre Klassen benutzen (und sich über XIncludeFile einbinden), dann kann temporär die eine Datei nicht erstellt werden. Aber es kann sein, daß das bei mir in der Praxis anders aussehen wird (hängt ja auch davon ab, wie man sein Projekt strukturiert), ich hab jetzt nur mal ein bißchen rumprobiert mit ein paar Testklassen und da ist mir das eben aufgefallen.

Ich kann dir nur wage folgen, bitte sende mir einen Link zu den Dateien als Zip Datei, damit ich das prüfen kann. Wenn du Vista hast MUSST du mindestens Revision 1.0r58 haben, vorher gab es einen Bug bzgl. des Festellens des PB Pfades.
http://pb-oop.origo.ethz.ch/wiki/changelog

Mir ist grad aufgefallen, daß ich gezwungen bin, erst alle Methoden und danach die Variablen zu deklarieren. Mache ich es andersrum, erhalte ich einen Garbage-To-The-End-Of-Line-Fehler. Wäre noch ganz schick, wenn Du das beheben könntest

Das geht deshalb nicht, da erst das "Interface" und dann die "Structure" im Code erfolgen, würde ich den Anwender Methoden und Attribute mischen lassen, wäre eine Debugger kompatible Ausgabe dahin. Und das ist imho Priorität. Schaue dir mal die Codeausgabe im User / Temp Verzeichnis von Windows an, wo auch sonst PB die Files temporär ablegt, dann wirst du verstehen was ich meine.

EDIT: Hab's rausgefunden über Flex also... okay, muß man wissen
Wäre schön, wenn wenigstens eine Warnung kommen würde, wenn man in einer abgeleiteten Klasse eine Methode deklariert, die in der Superklasse bereits existiert, aber nicht als Flex deklariert ist.

Mit allem Respekt und Ehren ..."Muss man wissen"? Steht doch alles genau in der Dokumentation? (Genauso wie das mit erst den Methoden und dann den Attributen in einer Klasse)
http://pb-oop.origo.ethz.ch/wiki/Polymorphism
Und bzgl. der Warnung? Warum? Das ist Polymorphie und das Prinzip hier ist wie bei C++, die Priorität liegt vorerst auf den Methoden der Basisklasse. Gehe ich jedoch hin und markiere die Methoden in der Basisklasse als virtuelle Methoden via "Flex" so wird diejenige der Masterklasse genutzt. Da spukt dir VC++ o.ä. auch keinen Fehler aus.

Muß aber noch ein bißchen Kritik loswerden, und zwar find ich es ziemlich unpassend daß der Konstruktor so heißen muß wie die Klasse, der Destruktor heißt aber Release(). Erstens gibt's sicherlich viele Klassen, bei denen man eine Release()-Methode für andere Zwecke hätte, und zweitens ist das insgesamt nicht besonders konsistent. Eine weitaus bessere Lösung wäre meiner Meinung nach Constructor() und Destructor(), oder NewObject() und DeleteObject() oder sonst irgendwas, aber KlassenName() und Release() ist meiner Meinung nach keine schöne Lösung.

Jeder will es anders haben ich weiss, daher sehe ich es nicht als Kritik, sondern als einen persönlichen Gusto, der vieles auch hier im nativen Purebasic anders sein lassen würde (siehe das Thema "ProcedureReturn").
Das Prinzip dieser OOP Implementation wird sehr den bewährten OOP Logiken anderer Sprachen entsprechen, aber jedoch weitestgehend mit einer soweit es geht PureBasic entsprechenden Syntax.
Ich habe mich dafür entschieden weil viele Programmierer es von C++ und C# her kennen und es sich auch so gut bewährt hat. Warum also das Rad neu erfinden.
This\Release() als aufzurufenden Destruktor wird bald obsolet in diesem Parser sein, da DeleteObject diesen sodann intern automatisch aufruft wenn vorhanden.

Konstruktoren und Destruktoren müssen/werden sodann gar nicht mehr manuell aufgerufen, das macht sodann alles NewObject und DeleteObject.

This\Release() ist hier genutzt worden weil es wenigstens zu Übergangszwecken ein wenig der Logik von COM Objekten entspricht.

Und noch was... das mit den PB-Keywords klappt bei mir immer noch nicht :/ -> hab's grad gemerkt, die EXE in Deiner r60-Version ist nicht die aktuelle, nur die in Deiner Standalone-Version. Hab sie ersetzt

Die r60 hat NICHTS an den Keywords geändert, ... sorry aber zu deiner Fett-Schreibweise: Im Changelog steht ganz explizit, dass r60 in seiner Unterscheidung nur etwas mit der Namensgebung des Standalone Plugins zu tun hat.
http://pb-oop.origo.ethz.ch/wiki/changelog
Wenn du bereits einmal den Installer genutzt hast, reicht es übrigens wenn du lediglich das Standalone PlugIn mit dem neuen überschreibst.

Dann gehe doch bitte mal in deiner aktuellen 4.10er PB Version hin und prüfe die Keyword Einstellungen in den Preferences! Bei jaPBe scheints ja deinen Post von der vorherigen Seite nach her zu stimmen.
Du solltest mir auch wie bereits in ein paar Beiträgen zuvor erwähnt dein PureBasic.prefs File zusenden. Please.


Lieber ZeHa ,
bevor du aber ausholst und wir hier aber über Syntax-Geschmäcker diskutieren, wäre es mir eine größere Hilfe, wenn man mir nicht nur sagt was nicht gut ist und was so vieles nicht klappt, sondern wenn du aktiv mir bei der Bugbeseitigung hilfst und das geht durch Beispiele von genutzten Codes und zusenden von Dateien (Prefs etc.).

Lese dir die Doku durch, wenn da etwas unleserlich vorkommt oder sie für dich im vorab Beta Stadium schlecht aufgebaut ist, dann sage es mir, denn das bringt mich weiter, nicht jedoch Unklarheiten, welche keine Sind, weil in der Doku bereits erklärt.

Ein Grund übrigens warum ich mich für jene Versionskontrolle bei Origo entschieden habe.

Jo kein Problem war nur grad so ein bißchen am Rumtesten und hab halt einfach mal alles hier abgeladen was mir so aufgefallen ist

Das mit der Doku: Ich gestehe, die hab ich nicht gelesen, weil Du eben einen hübschen Screenshot in Deinem ersten Posting hast, und ich dachte, daß dort alles relevante bereits drin ist. Daher habe ich das als Vorlage genommen und mir da kurz die Syntax-Regeln rausgezogen. Wäre vielleicht praktisch, wenn Du das Flex inkl. Kommentar auch noch einbauen könntest, und evtl. noch 'nen Dekonstruktor, weil dann dient dieser Screenshot als komplette Referenz. Du weißt doch daß keiner gerne Dokus liest und wenn einer OOP programmieren kann, will er in der Regel so schnell wie möglich einfach kurz die Syntax-Regeln haben und loslegen

Was die Warnung bei Nichtbenutzung von Flex angeht: Somit programmiert man sich halt Methoden, die niemals aufgerufen werden können. Und zumindest in Java gibt es sogar Errors bei "unreachable Code", und in Java ist auch die Priorität anders (hier werden abgeleitete Methoden bevorzugt). Da fällt mir auch gleich ein, ist eigentlich ein Cast möglich?

Nun zum Thema r60: Ich habe mir den aktuellsten r60-Installer gezogen und installiert, und da hat das mit den Macros eben nicht funktioniert. Als ich das Standalone-Plugin genommen hab und die EXE dann entsprechend ersetzt habe, ging es problemlos.
Oder ist r60 nur ein Update? Also daß der Installer nur kurz die EXE umbenennt? Ich ging davon aus daß das einfach die aktuellste, komplette Version ist.

Dann noch Konstruktoren und Destruktoren: Da ging's mir nicht um das manuelle Aufrufen, sondern rein um die Namensgebung. Naja, man kann sich damit anfreunden bzw. man muß es halt hinnehmen, aber ich wollt halt nur sagen daß das für mich sehr willkürlich aussieht. Aber wenn es unter C# auch Release() heißt, dann meinetwegen unter Java heißt es finalize(), find ich auch nicht so prickelnd. Unter D heißt es glaub this() und ~this(), aber gut, darüber will ich jetzt wirklich nicht streiten wenn Du Gründe dafür hast, dann ist das in Ordnung.

Nun zu der Sache mit den Abhängigkeiten... ich hab XP und das folgende funktioniert nicht:

Datei 1 Datei 2 Unter normalem PB müßte das allerdings problemlos funktionieren, da es sich ja um ein XInclude handelt. Der OOP-Parser gibt aber einen Fehler aus, nämlich daß er die jeweils andere Datei nicht erstellen kann.


EDIT: Hast Du eigentlich ICQ? Ich bin schon sehr an dem Projekt interessiert und freue mich wenn's so schnell und so gut wie möglich wächst, aber vielleicht sind solche Fehler usw. übers Forum etwas umständlich zu erklären daher wäre ICQ ganz praktisch

Hi Zeha,

ICQ habe ich leider nicht, bin nicht so der Chatter, lediglich AIM, aber viell. sind die kompatibel?
Denn ich habe alle Sachen zuhause auf meinem MacMini der neben dem OSx auch ein WindowsXP System laufen hat, ebenso wie Ubuntu 7.04 - ein klasse kleines Teil. Und eben jenes OSx hat iChat am laufen mit welchem ich via dem AIM Protokoll unterwegs sein könnte.

Wenn wäre ein Austausch sowieso nur dieses WE möglich, da ich
Werktags abends nur mein Notebook zur Verfügung habe und zu jener Zeit nicht nicht online sein kann.

Die Namensgebung mit den Destruktoren in der Klassendeklaration habe ich mir auch schon überlegt, wie gesagt, Release() ist man von COM her gewohnt.

XIncludeFile("datei2.pb")

Hast du es mal mit der Schreibweise wie in der PB Doku versucht, also XIncludeFile "datei2.pb" ?
Werde mir das aber nochmal ansehen.

Was die r60 angeht, das überrascht mich sehr
Das wird wohl dann irgendwie an 7z liegen oder was auch immer, denn ich öffne ein bereits vorhandenes 7z-zip Archiv, lösche den alten Installer und fügen den neuen ins Archiv ein. Es kann sein, dass da viell. was buggy ist, mit WinRar war das nie ein Problem.

Ich überlege mir sowieso den ganzen Installer hinzuwerfen und lediglich das PlugIn als einzelne Binary wie in der Alternative gehabt, anzubieten.
Die Keywords können sich die User dann in den Editoren selbst setzen und es gibt nicht mehr diesen ganzen Zirkus mit PB-Versionen und seinen .Pref's.

AIM läuft glaub auch über ICQ, schick mir einfach Deinen AIM-Nick per PM oder so.

Hab nochmal zwei Dinge festgestellt und Dir in den Bugtracker eingetragen.

Hi,

habe mir mal Dein erzeugen Code für OOP angeschaut und folgendes ist mir aufgefallen.

1. Release set nur den String zurück. Müsste aber das Object wieder freigeben.

2. Du verwendest AllocateMemory und FreeMemory. Dieses verursacht aber bei der Verwendung von String Speicherlecks da nur der Pointer auf den String gelöscht wird.

3. Die Verwendung von IncludeFiles() zum laden Klassen und dann die Verwendung der Objekte nicht möglich. Ich weiss das dieses zu lösen fast unmöglich, da sonst jede einzelne Includedatei ersetzt und übersetzt werden müsste.

Habe diese bei mir anders gelöst. Vieleicht findest du ja noch eine Lösung dazu.

Sonst funktioniert alles wie es soll

FF

@Zeha

Habe mal hier eine Vorabversion angehangen, bevor ich es in der Versionskontrolle einfüge:
http://pb-lounge.pb-club.de/viewtopic.php?p=51806#51806

- Unterstützung von abstrakten Klassen und -Methoden.
- Defined('CLASSNAME', #PB_Class)
- SizeOf
- OffsetOf

Was jenes von dir erwähnte Problem mit den Includes angeht kann ich nicht ganz nachvollziehen. Es muss in jaPBe immer die Datei abgespeichert sein, das ist alles, was mir aufgefallen ist, liegt aber an jaPBe, bei der IDE gehts ohne Probs.
Dateien mit mehreren "IncludeFile" Aufrufen habe ich getestet. Bestes sehr komplexes Beispiel ist das DX9 Klassen-Example von Hellhound:
http://pb-oop.origo.ethz.ch/system/files/PBOOP_DX9.zip
Funktioniert ohne Probleme.

Mk-Soft hat geschrieben:1. Release set nur den String zurück. Müsste aber das Object wieder freigeben.

Wie in der Doku vermerkt und auch 2 Postings oben von mir angegeben: \Release() ruf den Dekonstruktor auf. DeleteObjekt löscht das Objekt. Bald gibt es nur noch DeleteObject, welches intern sofern vorhanden autom. \Release() aufruft.

Die Verwendung von IncludeFiles() zum laden Klassen und dann die Verwendung der Objekte nicht möglich.

Ich kann dir momentan nicht folgen?
Lade ebenso oben mal das DX9 Klassen Beispiel von Hellhound, dort werden ja ebenso Klassen etc. via IncludeFile geladen.
Ich nutze generell immer die Syntax IncludeFile "myFile.pbi", also ohne Klammern.
Ansonsten bitte die letzte Version mit dem Bugfix nutzen, wo der PureBasicPfad in Vista richtig erkannt wird (siehe Changelog).
Denn sonst funktioniert IncludeFile #PB_Compiler_Home + "myFile.pb" nicht. Das ist nämlich mit Parsern und CompilerRuntime Direktiven immer so ein Problem.

Habe mal die aktuelle Standalone Version geladen.
Mit der geht auch die Includefiles

FF