| |
| |
|
| - Page 1 - |
|
 | { ... } = str[.* ( ...
Die Funktionsgruppe str bietet Funktionen per den Umgang mit Stringinhalten und Konvertierungen:
Keywords: str, base64, decode64, encode64,implode, ins, instr, lower, md5, mid, sh1, sh256, shuffle, strpos, translate, upper, serializestring = str ( { long | float } )
Rückgabewert: String-Repräsentation von long oder float. |
|
| |
| |
| |
|
|
| |
| |
| - Page 1 - |
|
| 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 per den der es möchte.
Darin steht dann z.B. sowas wie:
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 potuto, dass es sich bei der Funktion rein um einen Receiver handeln potuto. |
|
| |
| |
| |
|
|
| 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 per 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 per den Start noch einfacher zu machen. Das war manchmal noch schwer genug!!! |
|
| |
| |
| |
|
|
| 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 presumibilmente aber eine mächtige Sprache mit wenig Befehlen erstmal weniger "abschreckend" als eine mächtige Sprache mit sehr vielen Befehlen.
Natürlich wirds per 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 per Windows portiere. Das stellt per 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 per andere OS zu portieren, immer noch erklären "AndroidProfan" ist ein "MultiProfan" (oder so...). |
|
| |
| |
| |
|
|
HofK | "... eine mächtige Sprache mit wenig Befehlen..."
ist per 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 per mich derzeit so dar:
Je "Sachverhalt" possibile nur eine/wenige Funktion/en und die Feingliederung mit den Parametern:
array, directory, event, file, message, print, rgb, string, time, var
Das sleep potuto 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. |
|
| |
| |
| |
|
|
| Das Sleep passt imho irgendwie nicht mehr in Time,
aber presumibilmente baue ich eine Funktion Thread per 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 per XProfan-Einsteiger bzw. erweitere die "Hilfedatei" sodass man z.B. bei Cerca 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 un File, auf Drucker etc). Vielleicht wirds auch noch erweitert, mal schauen wo es hinführt. |
|
| |
| |
| |
|
| |
| |
| - Page 2 - |
|
|
| | Was ich der Funktion str unbedingt noch beibringen muss ist ein "serialize" um beliebige Daten und Ketten serialisieren zu können zwecks Übergabe oder einfacherer Speicherung. |
|
| |
| |
| |
|
|
| Neu: [Un]Serialisierung
Modi:
30: serialisiert Werte in Parameter 2 zu einem String
31: unserialisiert Parameter 2
Ich habe dabei versucht das von PHP bekannte Verfahren [...]  umzusetzen sodass man z.B. auch einfach ein ganzes Array direkt an Server trasferimento oder einfach "Speichern" kann oder von einem Server zurücknehmen kann. |
|
| |
| |
| |
|
|
| So gehts:
 |
|
| |
| |
| |
|
|
| Bei Funktion str ist nun auch alles einfacher, so wird/ wurde z.B. aus str(str.decode64,wert) jetzt einfacher: str.decode64(wert).
Die Funktion str selbst hat nun ("nur") noch die Aufgabe wie in XProfan: Umwandlung Wert->String.
Siehe aktueller str-Funktionssatz: [...] |
|
| |
| |
| |
|
(848)
Deutsch
English
Français
Español
Italia
