Infinity-Profan

Neu: löst Funktion mid ab:

Wenn 3 Parameter angegeben:

Gibt einen Teilstring zurück aus string ab Position long von mit long Anzahl Zeichen.

15.01.2015 ▲

Neu: Löst Funktion translate ab wenn Parameter

long,string

oder

string,string,string[,bool]

HofK

Es ist der generelle Trend zu erkennen Funktionen unter einem Oberbegriff zu vereinen und die spezifische Wirkung über die Parameter zu steuern.

Wenn ich mir unter dieser Prämisse die Referenz anschaue, sehe ich nun zu viele on... Funktionen kommen.

Zitat IF: "Was wäre wenn ich eine Funktion Event biete die gerufen wird sobald ein Ereigenis eintritt.
onbackpressed, onmenupressed, oder einfach onkey, onerror etc. könnten dann in der Funktion event abgegriffen werden. oder doch onevent?"

Dann also im Trend besser event oder onevent (da bin ich völlig relaxt) und als erster Parameter die Art des Ereignisses: menupressed, backpressed, error, touchstart, touchmove, ...

Wenn ich mir aber str nun so im praktischen Einsatz vorstelle, gibt es dann eventuell immmer wieder str( .....) und nochmal str(----) usw. und es könnte den Quelltext schwerer lesbar machen als eine Folge von mid, translate, base64 ... ???

Kompilieren Markieren Separieren

Ja, sowas ist auch meiner Meinung nach alles zum Nachteil der Leserlichkeit.

Darum habe ich mir das so gedacht, dass ich zum einen die Sprache so kurz fasse wie sie meiner Meinung nach sein kann, darf und sollte, und dann kann es eine Inc geben, die den Sprachschatz z.B. wieder auf eine lesbarere Variante bringt für den der es möchte.

Darin steht dann z.B. sowas wie:

proc toast(s)

    return msgbox(1,s)

endproc

proc mid(s,f,t)

    return str(s,f,t)

endproc

proc explode(arr,delim)

    return arr(arr,delim)

endproc

ums in xprofansche Richtung umzubiegen oder oder ...

Klaus Hoffmeister (16.01.15)

Dann also im Trend besser event oder onevent (da bin ich völlig relaxt) und als erster Parameter die Art des Ereignisses: menupressed, backpressed, error, touchstart, touchmove, ...

Sehe ich auch so.

Bei der Frage ob event oder onevent...

Da man die Funktion auch nutzen kann um Events zu feuern, erscheint mir die Bezeichnung event sinnvoller, auch weil das "on" implizieren könnte, dass es sich bei der Funktion rein um einen Receiver handeln könnte.

Str hat jetzt zudem auch noch die Funktion der Funktion ins$ bzw. insstr übernommen da sich ins$ erübrigt hat denn bei selben Parametern kanns auch str erledigen:

"Ha-llo" = str("Hallo","-",3)

Und nun ists auch der Funktion strpos an den Kragen gegangen, kann auch die Funktion str ohne Einbuße übernehmen:

str(heu,nadel)

oder

str(sucheAbPos,heu,nadel)

Es ist schon interessant, dass scheinbar alle wichtigen Stringfunktionen von einer einzigen Funktion erledigt werden können ohne dass es irgendwelche kuriosen Parameterdefinitionen geben muss.

HofK

iF (16.01.15)

Ja, sowas ist auch meiner Meinung nach alles zum Nachteil der Leserlichkeit.

iF (16.01.15)

Darum habe ich mir das so gedacht, dass ich zum einen die Sprache so kurz fasse wie sie meiner Meinung nach sein kann, darf und sollte, und dann kann es eine Inc geben, die den Sprachschatz z.B. wieder auf eine lesbarere Variante bringt für den der es möchte.

So fände ich es perfekt.
Da man als Anfänger lieber erst einmal ein paar Funktionen die sagen was sie machen und wenig Parameter haben ausprobiert, sollte die include oder header Variante Grundeinstellung sein. Einem Fortgeschrittenen kan man dann zumuten soetwas wie desable easymode zu schreiben oder in der IDE einen Schalter umzulegen.

Obwohl XProfan 11 ja schön übersichtlich daherkommt, hatte ich seinerzeit die langen Gesichter meiner Pflichtkursler vor Augen ersteinmal eine ext.ph gebastelt um Einfaches für den Start noch einfacher zu machen. Das war manchmal noch schwer genug!!!

XProfan 11

Wird halt eine Anweisung etwa wie:

include xprofan.util.aprf

Wer sich die Befehle etwa in Richtig Pascal oder C oder Java oder oder strecken will kann dann z.B.

include pascal.util.aprf

oder

include java.util.aprf

So grundsätzlich finde ich vermutlich aber eine mächtige Sprache mit wenig Befehlen erstmal weniger "abschreckend" als eine mächtige Sprache mit sehr vielen Befehlen.

Natürlich wirds für den gemeinen XProfaner erstmal eine Art kleine Umstellung bedeuten wenn er von XProfan ausgehend mit AndroidProfan programmieren möchte aber es sind halt nur wenige Befehle zu lernen und ich glaube das man da gut reinkommen kann.

Was übrigens auch ginge ist wohl das ich AndroidProfan für Windows portiere. Das stellt für mich aber leider auch den Namen deutlich infrage. Vielleicht hätte ich es danach besser sowas wie "multiprofan" nennen sollen. Ist aber egal denn ich kann auch später einmal, wenn ich wirklich Lust haben sollte für andere OS zu portieren, immer noch erklären "AndroidProfan" ist ein "MultiProfan" (oder so...).

HofK

"... eine mächtige Sprache mit wenig Befehlen..."
ist für die innere Logik/Sprachentwicklung sicher günstiger und die Idee mit "include xprofan.util.aprf, ...include java.util.aprf" finde ich prinzipiell gut. Es gibt dann aber Dialekte von AndroidProfan und die Programmierer verstehen sich untereinander so gut wie ein echter Friese und ein echter Bayer oder müssen in "Hoch(deutsch )androidprofan kommunizieren.

Zu den Funktionen stellt sich die Struktur für mich derzeit so dar:
Je "Sachverhalt" möglichst nur eine/wenige Funktion/en und die Feingliederung mit den Parametern:
array, directory, event, file, message, print, rgb, string, time, var

Das sleep könnte theoretisch bei time mitspielen? Bei directory/file gibt es die diskutierten Überschneidungen.

Bei übergreifenden Dingen: len, del, long auf Strings & Arrays anwenden.

Mit der Bezeichnung print habe ich immer ein Problem (Druckvorschau oder Ausdruck). Das printf (printformatted) in C ist mir aber noch unsympatischer. Irgendwas wie text, outtext, display, displaytext, out oder output ( vielleicht nicht nur Text, nicht nur auf dem Display?) ... würde ich vorziehen.

XProfan 11

18.01.2015 ▲

Das Sleep passt imho irgendwie nicht mehr in Time,
aber vermutlich baue ich eine Funktion Thread für Threads und da
würde es dann wiederum hineinpassen nach dem Motto Schlafesthread.

Das mit den Dialekten sollte man vielleicht erstmal abwarten. Vielleicht mache ich auch einfach eine Liste für XProfan-Einsteiger bzw. erweitere die "Hilfedatei" sodass man z.B. bei Suche von getdir$("@") dann auch chdir() findet.

Das mit Print ist so eine Sache, ist so etabliert wie cls. Print finde ich auch garnicht so "falsch" denn es geht ja ums Drucken nur halt in dem Fall auf dem Bildschirm (oder wie in XProfan in eine Datei, auf Drucker etc). Vielleicht wirds auch noch erweitert, mal schauen wo es hinführt.

18.01.2015 ▲