Ist es mit XProfan möglich eine eigene Containerfunktion zu erstellen? Mir ist schon klar, dass ich als ersten Parameter einen String abfragen kann und dann die Parameter per Overload behandel, aber das ist doch recht ungünstig. In meinem konkreten Fall geht es darum eine Funktion MyFTP zu erstellen, die ich mit Unterfunktionen füllen will.
Eigene Containerfunktion erstellen
-
-
-
Reicht SubProc nicht?
-
Geht nur wenn die Funktion an sich, also FTP oder Set, schon vorhanden ist. Sonst kommt "Funktion unbekannt".
-
Ja, ist momentan so.
Da hilft derzeit nur:
SubProc FTP.My_...
zur besseren Unterscheidung.
-
Geht da nicht was mit ASM ENDASM? Inlinecode-Procs werden ja auch wie eine "Externe Funktion" behandelt? Könnte RGH uns da was tricksen?
-
Vielleicht kannst du damit was machen :
Code
Alles anzeigenCls MyFTP("init", 100) MyFTP("upload", "Test.txt", "Profan.de") Proc MyFTP Parameters String befehl 'Print %PCount Select befehl CaseOf "init" Print @&(2) CaseOf "upload" Print "Parameter 1 : "; @$(2) Print "Parameter 2 : "; @$(3) EndSelect EndProc WaitKey
Käme dem Subproc schon sehr nahe.
Wenn der Code größer wird, würde ich in der CaseOf - Abfrage
die weiteren Procs aufrufen (init, upload).
Proc init
....
EndProcusw.
Wenn du es etwas aufwändiger haben willst, kannst du ja auch
noch mit %PCount und PType$() Anzahl und Typ der Parameter
abfragen. Dann brauchst du die @$() @&() usw. nicht. -
Das hatte ich schon mal versucht.
In MwDate hatte ich das bis zum Extrem ausprobiert.Das Problem sind aber die vielen unterschiedlichen Parameter-Leisten.
Dort kann man schnell den Überblick verlieren.Besser wäre, wenn Roland da eine Möglichkeit findet uns einen Container-Rohling zu bauen von dem wir dann neue Container ableiten können.
-
Das hatte ich Roland schon vor einiger Zeit gefragt.
Damals wurde mir gesagt, daß das schon ginge, nämlich
wie oben, mit der Punkt-Notation.Ich glaube auch nicht, daß das so einfach geht. Ein Container-Rohling
wäre zwar möglich, aber wie soll Roland im Voraus wissen, wie der
heißen soll ? So ein Container sollte ja schon andeuten, welche Art
von Funktionen drin enthalten sind. Bei MOVE(....) z.B. weiß ich
genau, daß in diesem Container alle Arten zum Verschieben von
Listeninhalten drin sind. Wenn ich mir jetzt einen Container Neu()
vorstelle und verwalte da drin alles mögliche Zeug, ist das nach
einiger Zeit auch nicht mehr übersichtlich. Wenn dann noch jemand
hingeht und die Get/Set/Create Container zusätzlich nutzt, und seine
z.B. Create-Funktionen in den Create - Container wirft, hat er irgendwann
das Chaos perfekt.Sowas ginge meiner Meinung nach nur mit einem variablen Container,
den man zur Laufzeit erzeugen kann und dann seine dazugehörigen
Procs reinwirft. Im Prinzip halt so ähnlich, wie die Array-Funktion, die
man virtuell an eine Funktion übergibt. Aber, ob sich das Führen von
extra Funktionslisten für Roland lohnt, sei dahin gestellt.
Das könnte dann so aussehen :Code
Alles anzeigenerg = Create("Container", "MyFTP") ' Ergebnis 0/1 Erfolg SubProc MyFTP.Init Parameters <...> .... EndProc MyFTP("Init",....)
Dabei müßte dann SubProc auch den Container erkennen.
Aber dazu müßte sich dann Roland äußern, was da machbar wäre.
-
Ganz so kompliziert muss man das mit den Parametern nicht machen. Da auf oberster Ebene außer der Abfrage nach dem Befehl ja nichts passiert, kann der Befehl Parameters auch in den Unterbefehlen ganz normal verwandt werden, nur dass da der erste Parameter nicht mehr interessiert:
Code
Alles anzeigenCls MyFTP("init", 100) MyFTP("upload", "Test.txt", "Profan.de") Proc MyFTP Parameters String befehl Select befehl CaseOf "init" Parameters String x, int zahl Print zahl CaseOf "upload" Parameters String x, par1, par2 Print par1 Print Par2 EndSelect EndProc WaitKey
Ich wüsste jetzt nicht, wie man das noch mehr vereinfachen könnte.Gruß
Roland -
Also, es geht natürlich recht einfach indem der erste Parameter ausgewertet wird und dann die entsprechende Unterfunktion angesprungen wird. Aber das stelle ich mir recht langsam vor.
Momentan habe ich meine FTP-Funktionen mit "My" gekennzeichnet, das ist auch ganz OK. -
Soooo langsam nun auch wieder nicht. Um an Deinem Beispiel FTP zu bleiben, das Langsamste ist die Datenübertragung. Da ist Profan selbst im Interpretermodus um Etliches schneller. Ich denke mal, die Laufzeit für die Decodierung der Subfunktionen wird Dir da gar nicht auffallen.
Gruß Volkmar
-
Möglich. Trotzdem wärs schöner wenn man sich 1,2,3 fix einene neuen Container erstellen könnte.
-
Bei sehr wenigen Unterfunktionen mag es ja noch recht übersichtlich sein.
Bei größeren Codes geht aber die Übersicht verloren. Da möchte man ganz
gerne auslagern, um eine Übersicht zu bewahren :Code
Alles anzeigenCls MyFTP("init", 100) MyFTP("upload", "Test.txt", "Profan.de") Proc MyFTP Parameters String befehl Select Lower$(befehl) CaseOf "init" Parameters String x, int zahl Init(zahl) CaseOf "upload" Parameters String x, par1, par2 upload(par1, par2) EndSelect EndProc Proc Init Parameters int z Print z EndProc Proc upload Parameters String par1, par2 Print par1 Print par2 EndProc WaitKey
Wenn dann noch mehr solcher selbstgebastelter Container hinzu kommen, weiß man zum Schluß
selber nicht mehr, welche Proc zu welchem Container gehört. Deshalb finde ich meinen obigen
Vorschlag mit den virtuellen Containern und den SubProcs übersichtlicher und eleganter.
Zumindest kann man dann mit subproc eine Proc richtig zuordnen. -
Daran sollte es wohl nicht scheitern. Die auzurufenden Prozeduren können ja MyFTP_Init u.s.w. heißen. Und ich verwende bei solchen "Zusammenhängen" schon mal den Trick, die Unterprozeduren in der Prozedur selbst unterzubringen.
Code
Alles anzeigenProc MyFTP Proc MyFTP_Init .... EndProc Proc MyFTP_Upload .... EndProc ' und hier beginnt dann die eigentliche Hauptprozedur. EndProc
Genau so gut kann man auch die ganzen zusammengehörigen Teile als eine eigenständige Datei (INC) speichern.
Gruß Volkmar
-
-
Das geht ja auch bei Incs.
-
Es hat mich trotzdem in den Fingern gejuckt. Es wird die frei definierte Containerfunktion geben:
Code
Alles anzeigenSubProc MyFTP.Init Parameters int zahl Print zahl EndProc SubProc MyFTP.upload Parameters string par1, par2 Print par1 Print Par2 EndProc Cls create("Container", "MyFTP") MyFTP("init", 100) MyFTP("upload", "Test.txt", "Profan.de") WaitKey
Gruß
Roland -
Da kann dann jeder seine eigenen Gelüste austoben? Und wie kriegt ein Neuer dann Hilfe? Ich bin nicht grundsätzlich dagegen, aber für sehr sparsamen Einsatz solcher Möglichkeiten ...
Und heißt das, es wird ein ÜBERDECKEN existierender Container-Befehle, also ein "Umdefinieren" geben?
-
Da kann dann jeder seine eigenen Gelüste austoben? Und wie kriegt ein Neuer dann Hilfe? Ich bin nicht grundsätzlich dagegen, aber für sehr sparsamen Einsatz solcher Möglichkeiten ...
Genau! Jeder kann nun eigene Container erstellen und diese mittels SubProc mit Funktionen füllen.
Und natürlich wird dies in der Hilfe seinen Niederschlag finden!Als Anhänger der Objektorientierung würde ich es trotz allem vorziehen eine Klasse MyFTP zu erstellen, die im Konstruktor die Verbindung aufbaut, und die restlichen Funktionen als Methoden enthält.
-
Danke, Roland!
-
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!