Eigene Containerfunktionen bauen

[Jac de Lad]

Hallo Roland.

Gibt es eine (vielleicht sogar für dich einfach umzusetzende) Möglichkeit, dass der Programmierer eigene Containerfunktionen definieren kann? Ich stelle mir das so in etwa vor:

Create("Container","Test")
subproc Test.Eins
...
endproc
subproc Test.Zwei
...
endproc

cls
Test.Eins
Test.Zwei
waitinput
end

Ich weiß nicht, wie du das intern in XProfan löst, vielleicht lässt sich das ja einfach umsetzen. Vielleicht auch im Präcompiler/-parser...

Jac

[RGH]

Zitat von Jac de Lad

Hallo Roland.
Gibt es eine (vielleicht sogar für dich einfach umzusetzende) Möglichkeit, dass der Programmierer eigene Containerfunktionen definieren kann? Ich stelle mir das so in etwa vor: ...

Hallo, Jac,
ich fürchte ich habe noch nicht ganz verstanden, auf was Du hinaus willst. Dein Listing würde so doch schon jetzt funktionieren:

proc Test.Eins
...
endproc
proc Test.Zwei
...
endproc

cls
Test.Eins
Test.Zwei
waitinput
end

Der Punkt im Bezeichner ist schließlich (zumindest noch) erlaubt, auch wenn ich zugeben muß, dass es dem Parser die Arbeit erschwert, eine Methode eines Objektes auf Anhieb zu erkennen.
Und wollte man objektorientiert programmieren, wäre ein Objekt mit statischen Methoden eine Lösung! (Siehe Kurs in der Hilfe.)

Gruß
Roland

[Jac de Lad]

Zitat von RGH

Hallo, Jac,
ich fürchte ich habe noch nicht ganz verstanden, auf was Du hinaus willst. Dein Listing würde so doch schon jetzt funktionieren:

proc Test.Eins
...
endproc
proc Test.Zwei
...
endproc

cls
Test.Eins
Test.Zwei
waitinput
end

Der Punkt im Bezeichner ist schließlich (zumindest noch) erlaubt, auch wenn ich zugeben muß, dass es dem Parser die Arbeit erschwert, eine Methode eines Objektes auf Anhieb zu erkennen.
Und wollte man objektorientiert programmieren, wäre ein Objekt mit statischen Methoden eine Lösung! (Siehe Kurs in der Hilfe.)

Gruß
Roland

Argh, das meinte ich natürlich anders:

subproc Test.Eins
...
endproc
subproc Test.Zwei
...
endproc

cls
Test("Eins")
Test("Zwei")
waitinput
end

So könnte ich mir zum Beispiel ganz einfach meine Process()-Containerfunktion bauen. Und jeder kann sie erweitern, was nicht geht wenn ich innerhalb der proc "Process" den String im ersten Parameter auswerte. Weißt jetzt was ich meine?

Jac

[RGH]

Ah, jetzt ja!

Aber ich fürchte, das wird nicht so ohne weiteres gehen. Da müsstest Du schon eine Prozedur/Funktion test schreiben (proc test), die den ersten Parameter auswertet und entsprechend reagiert.

Aber ich behalte den Gedanken mal im Hinterkopf ...

Im Übrigen sehe ich nicht ein, was bei den Process-Befehlen der Vorteil wäre, wenn es sich um eine Containerfunktion handelte. Aber vielleicht kannst Du mich ja überzeugen. Noch ist ja nichts festgeschrieben.

Gruß
Roland

[Jac de Lad]

Ich fänds sinnvoll, weil man sich da nicht mit ResumeProcress, PuasProcess etc. vollknallt, sondern alles schön in einem Container hat. So hast du es bei Tray() ja auch gemacht und das finde ich genau richtig. Halt irgendwie thematisiert...

[RGH]

Zitat von Jac de Lad

Ich fänds sinnvoll, weil man sich da nicht mit ResumeProcress, PuasProcess etc. vollknallt, sondern alles schön in einem Container hat. So hast du es bei Tray() ja auch gemacht und das finde ich genau richtig. Halt irgendwie thematisiert...

Hm, hm, ich werde noch mal drüber nachdenken ...

Was macht der Befehl "PuasProcess"?

Gruß
Roland

[Bangkok]

Wenn man mal von den 2 PExec.... absieht verbleiben noch 3 Funktionen mit höchstens 2 Parametern, da halte ich eine Containerfunktion für überflüssig sogar für viel umständlicher.

[Frabbing]

Die Funktionen zu containern ist doch auf jeden Fall nützlich. Das Thematisieren solch ähnlicher Funktionen ist viel übersichtlicher und selbst in der Hilfe findet man sie auch einfacher.

[Bangkok]

Würde dir ja recht geben, wenn es sich um eine größere oder ausbaufähige Gruppe handeln würde wie z.B. db(). Aber gerade bei den paar Funktionen, was soll nach Start, Pause, Ende und Wiederaufnahme eigentlich noch kommen, halte ich es für übertrieben.
Was ist nützlich daran wenn ich z.B schreibe Process("Resume",pid&). Unterm Strich ist das ja nur eine Verdrehung von ResumeProcess(Pid&), ist eins so schnell geschrieben wie das andere. Gut man könnte das PExec dann in process("PExec"....) umwandeln, was aber wiederum länger wäre. Da ich aber ja nicht im Akkord arbeite soll Roland tun was er für besser hält.

[RGH]

Hallo,

ich glaube, das mit der Containerfunktion würde dann noch besser in die XProfan-Logik passen, wenn dann aus pExec ein Create("Process", <Modul>, <Prozedur>, ...) würde, wie es ja auch bei anderen Objekten der Fall ist: Eine CreateFunktion und zur Behandlung des Erzeugten eine Funktion mit dem Klassennamen des Objektes.
Und was wird dann aus pExecWait? Da fällt mir dann auch etwas ein ...

... aber ich warte erst noch einmal ein wenig die Diskussion ab. Vor Sonntag werde ich eh' kaum Zeit für XProfan haben.

Am Freitag geht es früh los in Richtung auf Schalke, um da am Nachmittag und Abend die Eröffnungsfeier der Eishockey-WM und anschließen das Eröffnungsspiel BRD <> USA zu verfolgen. 78000 werden da sein und damit dazu führen, dass dieses Spiel ins Guiness-Buch der Rekorde als Eishockeyspiel mit den meisten Zuschauern eingeht. Und da wir da wohl eher erst so gegen 5 Uhr am Samstg früh zurück sind, kann es gut sein, dass ich große Teile des Samstags verschlafe ...

Gruß
Roland

[Jac de Lad]

@Bangkok: Das Containern dieser Funktionen wäre sinnvoll, weil man die dann leicht erweitern kann. Dafür sind Container ja da. Und bei Process ist das auch noch vieeeeel erweiterbar.