Aufruf an die Pure-Gemeinde [Module in PureBasic]

[Nino]

Warum verwendest Du für diesen Thread keinen Titel, der etwas über dessen Inhalt aussagt? Das wird hier jedem Neuling 10x unter die Nase gerieben. Als ich "Aufruf an die Pure-Gemeinde las", dachte ich Du willst versuchen einen unliebsamen Politiker abzusetzen, suchst einen Knochenmarkspender für einen schwerkranken Freund oder sonstwas.

[ts-soft]

Eine Umsetzen im PB-Stil wäre mein Wunsch. PB nutzt doch bereits sehr viele Module
mit eigenem Scope für globale Variablen, mit exportierten und privaten Funktionen,
sowie mit autom. ausgeführter Init und End-Funktion: siehe PureLibraries oder User-
libraries.

Eine Möglichkeit von UserLib per Source, die im Source-Dir, nur bei Veränderungen im Source,
jeweils vorweg, Neu kompiliert wird und auch nur im betreffenden Source nutzbar ist.

XIncludeLib "mylib.pblib"

Würde zu PB passen, hat nix mit OOP zu tun und würde die meisten der oben genannten
Probleme lösen.

Gruß
Thomas
PS:

PS: Linux, war da nicht was mit Unix und Xenix. Gibt es dat, wat ist dat. Essbar ?

Windows und PureBasic for ever !

Oh man
Wurden heute Tiefflieger angesagt?

[PMV]

EDIT:
Und für mich ist es das gleiche ob ich Engine.Particle.Create() nutze, weil ich zwei Module habe und darun eine Create() procedure
oder Engine_Particle_Create() weil ich im Include Particle was in Engine drin ist eine Procedure Engine_Particle_Create() definiert habe.

Richtig. Das ganze funktioniert tadelos bei mittleren ... in unserem
Fall können wir auch große Projekte überschauen und brauchen uns
keine sorgen machen, dass wir ausversehen etwas verwenden, was
wir vorher schon verwendet haben bzw. was durcheinander bringen.

Doch denk mal einen Schritt weiter. Was ist, wenn du nicht mehr
alleine arbeitest? Schon wen eine zweite Person dazu kommt wird es
bei großen Projekten unmöglich, hier alles zu überschauen. Klare
Regeln müssen zu beginn definiert werden. Und wenn diese von der
entsprechenden Sprache noch zusätzlich überprüft werden, ist das
immer nur ein Vorteil.

Für mich ist es gleich, ob ich ne OOP-Sprache hab oder "in prozedural
denken" soll. Andere haben es aber nicht so leicht und früher oder
später hat jeder vergessen, was er vor Jahren gemacht hat. Ist ein
Teil davon in sich geschlossen, kann man nix falsch machen. Auch
wenn man nach Jahren nur noch schwammige Erinnerung an das
"Wie" hat, man kann es verwenden ohne Angst haben zu müssen,
das eigene Projekt dabei zu vernichten, so lang man das "Was" noch
weis.

MFG PMV

[Franky]

Anmerkung: Der Text entstand vor PMVs Beitrag, bin aber noch nich zum abschicken gekommen.

Aus meiner Sicht wären sowohl Modules als auch etwas erweiterte OOP-Ansätze richtig.
Ich hoffe ja auch immernoch, dass endlich mal mehrzeiliger Code eingeführt wird (nicht als default, sondern z.B. per "_" am Zeilenende).

Ich glaube aber, dass die Frage nach Modules und OOP zunehmend auch auf erweitertes Interesse am Produkt PureBasic deutet.
PureBasic ist immernoch ein Nischenprodukt, aber der vermehrte Einsatz in Unternehmen ist klar zu erkennen.
Dazu muss man nur mal im Forum umschauen, das ist in den letzten Jahren IMHO viel mehr geworden.

Da ist jetzt die Frage, ob die Anwender das überhaupt wollen.
Schließlich muss man ja bei Programmierern unterscheiden:

Die Teilzeit-Hobby-Programmierer im solocoding
Ich gebe den Leuten recht, die sagen, dass sie PureBasic lieben, weil es so ne schön kompakte Sprache ist, mit der man sich sehr
schnell mal ein kleines Tool oder ein Spiel als Wochenendprojekt zusammenschreiben kann. Ich liebe es auch, dass PB "reiner" Quelltext ist, nicht wie bei Delphi oder VB, wo man erstmal einen Überladenen Visual-Designer hat, den man extra austricksen muss, um sich die Event-Schleife frei zu gestalten. Wenn dann Projekte nicht als QuelltextDateien, sondern als XML-Dateien oder am besten noch als irgendwelche Binärkonstrukte vorliegen, geht das IMHO garnich klar.


Die Vollzeit-Opensource-bzw.-Berufsprogrammierer
Hier muss man beachten, dass nicht einer am Programm arbeitet, sondern viele. Und dass es auch sein kann, dass ein völlig unbedarfter das Projekt vielleicht mal übernimmt. An dieser Stelle muss dann auch etwas mehr Ordnung mit ein bisschen mehr "BigBrother" dabei eingesetzt werden. Ich denke nicht, dass PureBasic sich diesem Finanzstarken Anwenderbereich fern halten sollte, da können wir alle nur von profitieren. Oder hätte einer von euch ein Problem damit, wenn der Chef sagt "Das nächste Großprojekt wird in PureBasic umgesetzt"? (Vorrausgesetzt natürlich, Code- und Projektmanagement passen)

Module: Der Compiler von PureBasic ist sau schnell, die Frage ist, ob ein modularer Compilierungsprozess ihn zu sehr bremsen würde. Unumstritten ist aus meiner Sicht aber der Vorteil interner Variablen und Funktionen mittels Public und Private. Zum Einen wird es so einfacher, fremden Quelltext ein zu binden, ohne Wechselwirkungen zu erzeugen. Mal im Ernst, wenn ihr ein Include einbindet und die Fehlermeldung "Structure Punkt is already declared" kriegt und dann seht "AHA, Member sind x und y, hab ich bei meiner auch", achtet ihr dann darauf, welchen Typen die haben und ob ihr die Structure ohne weiteres ersetzen könnt? Das ist jetzt nur mal ein Beispiel, welche Probleme es mit Includes geben kann. Und spart euch "ja, ich achte da immer drauf". Nobody is perfect.
Ein weiterer Vorteil ist, dass bei einer Übernahme des Projekts bzw. bei einer Einarbeitung als neuer Mitarbeiter schwerwiegende Fehler vermieden werden. Beispiel: Kommunikation über RS232 mit einer Steuereinheit für Hydraulikventile. Die Funktion "Baggerarm_Senken" sollte Private sein und nur innerhalb von "Baggerarm_Senken_Falls_OK" aufgerufen werden. Ein Neuer würde wohlmöglich "Baggerarm_Senken" aufrufen und dann den Porsche vom Chef nicht beachten, den der Umgebungssensor erfasst und in "...Falls_OK" gemeldet hätte. (Merkt man, dass Ich grad an Mobilhydraulik arbeite? )

OOP: Ich finde es absolut überflüssig, alles in OOP zu packen. Es gibt aber aus meiner Sicht durchaus Stellen, an denen es Sinnvoll ist. Beispiel wären hier fliegende Raketen in einem SpaceShooter. Viele einzelne Elemente, die eigene Eigenschaften haben.
Aus meiner Sicht sollte man vor allem "SELF" noch einführen und zumindest ein offizielles HowTo zur Verwendung von Interfaces herrausgeben. (Wenn es so ein offizielles HowTo schon gibt, verbessert mich bitte.)
Zu den ganzen PreCompilern: Ich finde es toll, dass sich Leute daran setzen, so etwas zu schreiben. Ein Hobbyprogrammierer wird auch sicherlich seine Projekte darin schreiben können. Einige PreCompiler sind OpenSource, sodass man, wenn der Programmierer es denn leid ist selbst daran weiter entwickeln kann. Hobby halt.
Im professionellen (wirtschaftlichen) Bereich sieht es da aber IMHO schon anders aus. Erstens baut man mit dem PreCompiler eine weitere Fehlerquelle ein, zweitens sind es Hobbyprojekte, bei denen man keinen direkten Ansprechpartner hat, drittens wird eine Firma
sich nicht auf die Idee einlassen, den PreCompiler selbst weiter zu führen, falls die Entwicklung eingestellt wird.

Wichtig wäre IMHO auch, das Projektmanagement weiter zu entwickeln, ohne rein auf Projekte zu setzen. Aber Dinge wie Versionsverwaltung sollten angeboten werden. Freaks Ansatz, eine DLL-Schnittstelle für die GUI zu entwickeln ist super, wichtig für Zusatzfunktionen ist aber aus meiner Sicht auch, dass nicht jede Zusatzfunktion ein eigenes Fenster braucht, sondern dass man es in einem oder maximal 2 Fenstern erschlagen kann.

Wenn dann noch die Revolutionäre Idee kommt, wie man den Quelltext richtig kommentiert (Mein Vorschlag wäre eine Autovervollständigung nach ";": "GRUND: ,Autor: , Datum:, Beschreibung:(Als Nutzung für Variablen und Funktionen),ACHTUNG: ). Wohlgemerkt, nicht ganz ernst gemeint.
Aber es gibt doch nix schlimmeres als "GUI_Aufbauen();Baut die GUI auf".

Achja, und wenn ich eine Art von FeatureRequests nicht mehr sehen kann ist das sowas wie "mehr Mathefunktionen" oder "DesktopCaretX() and DesktopCaretY()". Aus meiner Sicht sollte man Fred nicht damit aufhalten, dass ER für uns Funktionen schreibt. Ich denke, das wichtigste ist, dass er die Sprache an Stellen erweitert, die wir nur schwerlich bis garnicht selbst bewerkstelligen können und die Auswirkungen auf das Aussehen des Quelltextes haben.


So, my 2€s

Mfg Franky

[X0r]

Eine sehr differenzierte Meinung, die du hier ausgeführt hast, danke franky.

Aber bitte vergesst nicht, dass Fred unsere Meinung nur im englischen Board wahrnehmen kann.
Wer also dafür ist, bitte hier seine Zustimmung kundtun:
http://www.purebasic.fr/english/viewtop ... =3&t=16224

Wenn wir genug sind, wird Fred früher oder später nachgeben, bzw. sich nach 6 Jahren mal überhaupt wieder dazu äußern.

Vielen Dank!

[DrShrek]

Ich erkenne noch immer keine zwingende Notwendigkeit für Module. Sorry.