Wunsch an die Purebasic-Entwickler

[reiner jakob]

Voraus ich bin Purebasic-Fan und möchte mich mal ganz nebenbei bei allen bedanken die zum Gelingen des Gesamten beitragen.


mein Wunsch Lokale Proceduren ich will sie mal lokadure() nennen.

Sie würden innerhalb einer Procedure programmiert und auch nur innerhalb der Procedure aufgerufen werden.
Sie können globale Variablen verwenden nutzen aber im wesendlichen Protected und Static Variablen

Vorteile :
man würde innerhalb größerer Projekte mit deutlich weniger Globalen Variablen auskommen (eventuell weniger als 20%)
die quasi Kapselung würde innerhalb einer Programmseite viel mehr Programmcode aufnehmen
Proceduren könnten deutlich leichter extern geschrieben und ausgetestet werden und mit kleinstem Aufwand eingebunden werden.
damit könnten größere Programmiergemeinschaften zusammenarbeiten und größere Projekte deutlich schneller bearbeiten.
Lokadure() Namen wären ausserhalb der umhüllenden Procedure nicht bekannt und könnten wiederverwendet werden, was zu diversen Vereinheitlichungen führen würde.
Da es sinnvoll ist solche Module nicht zu groß werden zu lassen könnte man zu gunsten einer schnelleren Verwirklichung auf Übergabeparameter verzichten.

Vieleicht sind je welche unter euch, die die Tragweiten verstehen und meinen Wunsch verstärken.
ich bin auf jeden Fall gespannt

Reiner

[ts-soft]

Hallo Reiner,

Wünsche und Verbesserungsvorschläge sollten, damit sie auch Gehör finden, hier:
Feature Requests and Wishlists
im englischem Forum geäußert werden.

Dein Wunsch ist aber schon mehrmals geäußert worden. Der Programmierer von PureBasic hat sich
hierzu auch positiv geäußert, aber bis das umgesetzt ist, könnte es dauern (seit 11 Aug 2005 warten wir)
Siehe auch hier: http://www.purebasic.fr/english/viewtop ... 486#p98486

Gruß
Thomas

[NicTheQuick]

Das wäre doch dann auch nichts ganzes und nichts halbes.

Was du eigentlich willst, sind Scopes bzw. Namespaces, wie sie von C bekannt sind. Das wäre in der Tat nützlich. Und da Scopes zunächst mal nur statisch sind und sie in jedem Programm nur einmal existieren, wurde später die objektorientierte Programmierung immer beliebter.
Dass OOP in PB nicht kommen wird, steht ja schon fest. Aber vielleicht hast du Glück mit Scopes und Namespaces.

Weiterhin gilt aber der Post von ts-soft. Wünsche und Anregungen gehören ins englische Forum. Da liest der Entwickler von PB selbst mit.

[X0r]

Ja, das wäre schon eine ziemlich geniale Sache.
Eventuell müssen wir halt mal ein Voting im englischen Forum starten.

[ZeHa]

Ich glaube Du meinst "innere Funktionen", das hat nichts mit OOP zu tun (@ NicTheQuick) und ist tatsächlich eine feine Angelegenheit. Man braucht sie jetzt nicht ständig und überall, aber z.B. in Python verwende ich sie schon hin und wieder. Auch sehr praktisch wenn man z.B. etwas rekursives programmieren muß, dann legt man die rekursive Funktion einfach als innere Funktion an, und die äußere ist dann diejenige, die die Rekursion in Gang bringt. Da die innere ansonsten i.d.R. eh von niemandem aufgerufen wird, ist das wie gesagt eine sehr übersichtliche Sache. Zumal man dann auch innerhalb eines kompletten Moduls mehrere rekursive Funktionen haben kann, die einfach nur "recursive" heißen. Somit braucht man sich nicht ständig irgendwelche dummen Namen auszudenken

[X0r]

Am interessantesten wäre das ganze für Libs. Dann kann man sich die ganzen dummen Prefixe/Suffixe sparen.
Konsequent wäre es natürlich dann auch, das ganze auf die PB-internen Libs zu übertragen:

Code: Alles auswählen

import PBGUI
OpenWindow(...)

oder

Code: Alles auswählen

PBGUI.OpenWindow(...)

Wäre doch keine schlechte Idee, oder?

[DarkDragon]

Ich glaube Du meinst "innere Funktionen", das hat nichts mit OOP zu tun (@ NicTheQuick) und ist tatsächlich eine feine Angelegenheit. Man braucht sie jetzt nicht ständig und überall, aber z.B. in Python verwende ich sie schon hin und wieder. Auch sehr praktisch wenn man z.B. etwas rekursives programmieren muß, dann legt man die rekursive Funktion einfach als innere Funktion an, und die äußere ist dann diejenige, die die Rekursion in Gang bringt. Da die innere ansonsten i.d.R. eh von niemandem aufgerufen wird, ist das wie gesagt eine sehr übersichtliche Sache. Zumal man dann auch innerhalb eines kompletten Moduls mehrere rekursive Funktionen haben kann, die einfach nur "recursive" heißen. Somit braucht man sich nicht ständig irgendwelche dummen Namen auszudenken

Ja, das ist durchaus nützlich bei Änderungen in den Startwerten/zusätzlichen Startwerten (die gekapselt sein sollten) einer Rekursion.

Aber Namespaces/Modules/Packages etc. wären natürlich auch ganz nett.

[inc.]

man würde innerhalb größerer Projekte mit deutlich weniger Globalen Variablen auskommen (eventuell weniger als 20%)

Globale Variaben machen den Code bei größeren Projekten eh in Teilen schlecht nachvollziehbar. Ich habe die Nutzung von globalen Variablen bei mir
um ca. 95% gesenkt, wenn ich bei prozeduraler Programmierung mit Kontext-Strukuren arbeite. Übringens, hier unten im Beispiel Inkl. dem Ansatz "innerer Funktionen":

Code: Alles auswählen

Structure ModuleContext
  variable.l
  signal.l
  foo.l
  bar.l
  *Procedure._prototype_Procedure
EndStructure


Procedure Module_Init()
  *ctx.ModuleContext = AllocateMemory(SizeOf(ModuleContext))
  
  if *ctx
     ; // Standardwerte setzen

    *ctx\blabla =10
    *ctx\foo =10
    *ctx\bar =10
    *ctx\Procedure = @Proc()
  
    ProcedureReturn *ctx
  EndIf
EndProcedure


Procedure Function(*ctx.ModuleContext, var.l, type.l,)
  *ctx\variable = var
  *ctx\Procedure(*ctx, type, "hello")
EndProcedure


; ///////////////////////////

*MyApp.ModuleContext = Module_Init()

Function(*MyApp, 100,10)

[reiner jakob]

Ich fühle mich nicht von jedem verstanden
auf keinen Fall will ich hier eine Lanze für objektorientiertes Programmieren brechen.

Deshalb zur Erklärung ein ....dämliches Programm_Beispiel

Code: Alles auswählen

+ Procedure.f  kosten_für_zimmer_neu(länge.f,breite.f, höhe.f)     (gefaltet)
 
  
-  Procedure.f  kosten_für_zimmer_neu(länge.f,breite.f, höhe.f)  ungefaltet
   protected   Euro_farbe_pro_m2,
   static
+ locadure.f   Bodenbelegen ()
+ lokadure.f  Decke_streichen() 
+locadure.f  Wand1_Tapezieren()
+lokadure.f  usw...
- lokadure.f Türrahmen ()
  .....Programmtext
  endlokadure () 

   procedureprogrammtext
  und
  und
  procedurereturn (Bodenbelegen()+Decke_streichen()+Wand1_Tapezieren()+ ---+.                ).
 
 Endprocedure 

Der Programmcode befindet sich auch für andere gut nachvollziehbar beieinander, versteckt sich in nur ein einer Faltung und hat seine eigenen Variablen interhalb der Procedure, die für alle internen lokaduren gelten.

Purebasic hat in der Zeile oben Platz für viele Programmtexte.
Wenn aber Porgrammcodes größer und größer werden, sind selbst die tolle Faltung
plus die obere Programmtextzeilen bald am Ende.

Würden die Proceduren zum Container um ihre eigenen internen Routinen, könnte die erreichbare Komplexität leicht vervielfacht werden.
Reiner
codetags geschwurbelt - bobobo

[inc.]

Ich fühle mich nicht von jedem verstanden
auf keinen Fall will ich hier eine Lanze für objektorientiertes Programmieren brechen.

Hat mit OOP wenig zu tun. Intern arbeitet PB mit seinem Objektmanager genauso.
Ist viell. nicht genau das was Du meinst, erreicht aber damit ähnliches ohne am Paradigma zu schrauben.