Aufruf an die Pure-Gemeinde [Module in PureBasic]

[X0r]

Liebe Pure-Community,
wir alle müssen wohl zugeben, dass PureBasic hinsichtlich des Code-Managements auf der Strecke geblieben ist. Wo andere BASIC-Sprachen wie z.B. BlitzMax sehr modern orientiert sind, OOP und/oder modulare Programmierung unterstützen, verharrt PureBasic noch bei BASIC-Strukturen des letzten Jahrtausends.

Ich bin kein Revolutionär und habe schon lange Frieden damit geschlossen, dass PB kein OOP unterstützen wird. Aber was spricht gegen modulare Programmierung? Würde das auch, wie Fred gerne argumentiert, die Community "spalten"? Wohl kaum!
Es würde die Sprache viel flexibler und vor allem attraktiver machen.

Deswegen bitte ich euch, in diesem Thead: http://www.purebasic.fr/english/viewtop ... 4&start=30
eine positive Meinung kundzutun, ich habe ihn bereits gebumpt.

Vielen Dank!

[DarkDragon]

Ich bin kein Revolutionär und habe schon lange Frieden damit geschlossen, dass PB kein OOP unterstützen wird. Aber was spricht gegen modulare Programmierung? Würde das auch, wie Fred gerne argumentiert, die Community "spalten"? Wohl kaum!
Es würde die Sprache viel flexibler und vor allem attraktiver machen.

Ähm Fred hat in dem Thread folgendes geschrieben:

This module concept sound good for bigger projects, and we will think how to implement it cleanly.

[DrShrek]

Glaubst Du das Module PureBasic wirklich weiterbringen werden?
Das es sinnvoll und nützlich ist sehe ich schon, aber...
... es gibt Sachen die deutlich wichtiger sind:

z.B.:
Endlich mal eine richtiges Framework für 3D Zeugs (nicht nur Games)
Ob es Irrrlicht, Ogre3D, usw... ist, ist eigentlich egal.

[STARGÅTE]

Liebe Pure-Community,
wir alle müssen wohl zugeben, dass PureBasic hinsichtlich des Code-Managements auf der Strecke geblieben ist. Wo andere BASIC-Sprachen wie z.B. BlitzMax sehr modern orientiert sind, OOP und/oder modulare Programmierung unterstützen, verharrt PureBasic noch bei BASIC-Strukturen des letzten Jahrtausends.

Ersten bin ich (einer von den "alle") nicht dieser Meinung!
Und zweites sollte Purebasic bei der "BASIC-Strukturen des letzten Jahrtausends" bleiben!
Ich verstehe es nicht wieso PureBasic OOP braucht, nur weil es andere Sprachen auch haben.
Sry geht einfach nicht in mein Kopf.
Und modulare Programmierung ist genauso unnötig!

Ich kann nur hoffe das die meisten nicht diesem Aufruf folgen, ich zumindest nicht.

[c4s]

Ich kann nur hoffe das die meisten nicht diesem Aufruf folgen, ich zumindest nicht.

Wie?
Solange es optional bleibt sehe ich da überhaupt kein Problem, sondern einfach eine nützliche Erweiterung für diejenigen die es brauchen und wollen... und Fred sowieso schon zugestimmt hat (zugegeben vor einigen Jahren), sieht er das anscheinend genauso.

[STARGÅTE]

"nützliche Erweiterung" heißt aber, das wieder eine Schiene mehr dazu kommt, die parallel weiter entwickelt und gewartet werden muss.

Klar, mir kanns egal sein, solange das Pure in Basic nicht zu kurz kommt.

Es ist vermutlich auch einfach nur ein Vorurteil von mir, wenn ich annehme das immer Leute von Basic-Fremden Sprachen zu uns kommen und PureBasic sachen von deren Sprachen aufzwingen wollen.

Mal sehen wo das hinführt ...

[hjbremer]

zuerst einmal, was versteht man unter "modulare Programmierung" ?

XInclude und Projekte scheinen es ja nicht zu sein. Gibt es ja schon.

Und wenn ich OOP will, würde ich VB lernen, aber da ich das Interface Zeugs kaum verstehe, wie soll ich da OOP verstehen

Viel lieber hätte ich Befehle für Edit im ListIconGadget, bessere Requester, sei es Print oder Dateirequester. Selbst wenn es diese unter Linux nicht gibt.

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

Windows und PureBasic for ever !

[X0r]

Ich zitiere mal:

Well, modules are basically libraries that stand on their own.
It's just a term used to describe a group of functions / classes etc.

But modules can also contain namespaces.
In my example, the first (or the outmost) namespace would define the module
that can be compiled separately. Let's not confuse that.

Kurz und knapp: Module sind in sich geschlossene Programmbausteine.

Hier mal ein Pseudo-Code von mir, meine Vorstellungen illustrierend:

Code: Alles auswählen

Module Engine

  Public Procedure Start(...)
  
  EndProcedure

  Public Module Particle
  
    Public Procedure Create(...)
    
    EndProcedure
  
  EndModule

EndModule

Benutzen würde man das ganze folgendermaßen:

Code: Alles auswählen

ImportModule Engine

Engine.Start(...)

Engine.Particle.Create(...)

In diesem Beispiel hätte man das Modul-Prinzip auf eine Lib angewandt. Interessanter wird es, wenn man das ganze auf die interne Struktur einer Anwendung überträgt.

Du hättest am Ende also im Prinzip ein Programm, welches aus kleinen, in sich geschlossenen Bausteinen besteht, die miteinander interagieren. Daraus ergeben sich im Vergleich zum üblichen Globals-und-Prozeduren-Zusammengeklatsche so viele immense Vorteile...
Der wohl größte Vorteil ist die Strukturierung und das Management des Codes. Dadurch wirkt er einfach klar und sauber getrennt, ist weniger fehleranfällig und man weiß immer, welche Funktionen, Globals etc. des Codes zu welchem "logischen Programmabschnitt" gehören. Hinzu kommt, dass Module nicht einfach wie Includes in den Code "eingebunden" werden. Sie können in kompilierter Form vorliegen. Dadurch muss man bei Änderungen eines Bausteins nicht gleich alles kompilieren.

[STARGÅTE]

Du hättest am Ende also im Prinzip ein Programm, welches aus kleinen, in sich geschlossenen Bausteinen besteht, die miteinander interagieren. Daraus ergeben sich im Vergleich zum üblichen Globals-und-Prozeduren-Zusammengeklatsche so viele immense Vorteile...
Der wohl größte Vorteil ist die Strukturierung und das Management des Codes. Dadurch wirkt er einfach klar und sauber getrennt, ist weniger fehleranfällig und man weiß immer, welche Funktionen, Globals etc. des Codes zu welchem "logischen Programmabschnitt" gehören. Hinzu kommt, dass Module nicht einfach wie Includes in den Code "eingebunden" werden. Sie können in kompilierter Form vorliegen. Dadurch muss man bei Änderungen eines Bausteins nicht gleich alles kompilieren.

Und genau deswegen gehts nicht in meinen Kopf. Das sind schlicht und einfach Includes mit ein paar mehr Schlüsselwörtern!
Wenn man seine Includes vernünftig aufbaut, dann sind auch Includes in sich geschlossene Bausteine (die zu jeder Zeit für sich alleine Funktionieren würden). Anderrum kannst du auch Module vermutlich so zerschrotten, das man weniger Überblick hat als vorher.
Zumindest habe ich Includes noch nie als "Code-Spalter" gesehen, die 20k Zeilen zu 2 mal 10k Zeilen machen,
sonden als Bausteine, die jeweils bestimmte Aufgaben erfüllen sollen.
Mit XInclude und Define() hat man auch nie probeme das sich sachen überlagern.
Obwohl die Bausteine ja eh unterschiedlich sind, sodass es eigentlich nie dazu kommt.
Und wenn ich "kompilierte Includes" haben will, nutze ich DLLs.

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.

[CNESM]

Ich finds gut, dass PB da anders ist, denn wenn PB so wäre wie die vielen anderen Sprachen, wäre es genauso schnell von meinem Computer verschwunden wie die vielen anderen Sprachen, die ich ausprobiert habe. Vorteile bietet es, aber ich finde es nicht lebensnotwendig für eine gute Sprache. Das Team von PB ist klein und solch eine weitere Schiene wäre neben den anderen Entwicklungen (Linux usw.) einfach nicht machbar bzw. würde PB im Endeffekt nur das Leben schwer machen.

Und wer sagt, dass PB von anderen Sprachen lernen muss? Gibt doch auch genug wo die anderen Sprachen von PB lernen können beispielsweise die super coole Community