| |
| |
|
 | Stark bleiben und durch den Text.
Momentan ist es ja so:
arr
chdir
chr
cls
del
device
display
event
exec
fattr
fcopy
fdel
float
fread
fwrite
gps
gui
http
len
long
math
msg
ord
phone
print
rgb
rnd
round
sleep
str
time
trim
Das muss besser gehen.
Klaus zeigte auf Del, und das es nach Str könnte.
Das stimmt natürlich. Hatte ich aber deshalb nicht so gemacht, da str nur dann eine übliche Funktion (wie mid, str$, translate$...) umsetzt, wenn auch die Parameter dann wie bei den jeweiligen Funktionen in üblicher Reihenfolge übergeben werden könnten.
Deshalb geht
str(s,2,3) als
mid$(s,2,3)
oder
str(s,f,r) als
translate$(s,f,r)
oder
str(20) als
str$(20)
bei Del war dies dann nicht mehr möglich, wären die selben Parameter wie mid:
str(s,1,2)
mid(s,1,2)
del(s,1,2)
klar könnte man nun:
str(1,2,s) als
del(s,1,2) -
aber das wäre erstmalig abweichend von einem gewissen Standard.
Darum hatte ich del einzeln. So auch bei anderen Funktionen.
Bin aber nicht zufrieden.
Idee: Bessere Schlüsselworte.
Beispiel:
es gibt len und width und fattr für filesize.
warum nicht nur len oder width, len oder width auf ein file könnte filesize geben.
Aber width(file)? Ist doch Murx, auch len(FILE file) ist Murx.
Width("Hallo") könnte natürlich 5 sein.
Warum also nicht einfach eine Funktion size und kein width mehr und kein len.
print size(string "Hallo")
print size(file "/...")
print size(display) /// könnte ein array ergeben [xx,yy,"width"=xx,"height"=yy]
Quasi ein noch ultra kompakterer Sprachkern.
Bitte keine "ist nicht übersichtlich"- Hinweise, denn das was ich meine, soll besser und übersichtlicher sein als Basic.
Experiment:
del
get
set
dir
file
float
int
string
copy
device
display
exec
gps
gui
http
msg
phone
print
rgb
rnd
round
size
sleep
time
trim
abschaffbar da theoretisch rein durch syntax herbildbar
arr
-
das wären dann 25 Befehle statt 32 und damit wäre eindeutiger ableitbar.
am beispiel:
file del f //fdel
file set f s //fwrite
file get f //fread
file size s
auch kürzer mgl:
file del f
file f s
file f
file size f
also statt fread,fwrite,filesize,fdel nur noch allgemeinere Schlüsselworte: file, del set get size - Schlüsselworte die wiederum auch in den anderen Befehlen verwendet werden könnten.
Ist halt ein Gedankenexperiment.
Die andere Variante ist die XProfane oder noch exzessiver wie bei PHP: Ultra-viele-Befehle deren Namen schon ziemlich gut deren Funktion beschreiben. sowas wie createImageFromPng etc.
Aber vielleicht bekommen wir ja das genaue Gegenteil hin und bieten die Langbefehlsnamen dann per xprofan.api.
Ich meine, wenn nicht jetzt zu Beginn der Entwicklung der Sprache, wann dann solche Überlegungen... |
|
| |
| |
| |
|
|
E.T. | Ich glaub der Gedanke gefällt mir  |
|
| |
| XProfan X3Grüße aus Sachsen... Mario  WinXP, Win7 (64 Bit),Win8(.1),Win10, Win 11, Profan 6 - X4, XPSE, und 'nen schwarzes, blinkendes Dingens, wo ich das alles reinschütte... | 12.12.2015 ▲ |
|
| |
|
|
Jörg
Sellmeyer | Die Idee find ich sehr schön. Ein paar solcher Sachen sind ja auch in XProfan schon angedeuted. Z.B. sind die ganzen Move-Funktionen alle unter einem Dach.
Was ist dann aber mit Dopplern wie:
Size(File "/...")
und
file size s
Sollen solche Sachen zweimal zugänglich sein oder lieber auf eins beschränken. Also entweder von der Funktion (im Sinne von Aktion) her oder vom Objekt. |
|
| |
| |
| |
|
|
| Genau,
dafür hätte ich die Lösung parat:
size und file sind a) Konstanten und b) Funktionen
So kann size file f erkannt werden so size(file,f) und aber auch file size f zu file(size,f)
Hindernis: Der Space-Operator bei:
size file f
er kann nicht wissen ob size(file(f)) gemeint ist oder size(file,f). |
|
| |
| |
| |
|
|
HofK | Da beißen sich dann zwei Dinge noch kräftiger, die auch jetzt schon ein Problem sind.
Momentan also die variable Parameteranzahl und die Deutung durch den Space-Operator.
Auf den möchte ich aber nicht mehr verzichten, auch wenn eben bei
print "Test" rgb(255 3 32) rgb( 0 255 128) // eine Klammer könnte noch wegfallen
die Klammern nicht mehr beide entfallen können, da die Tranzparenz "im Wege" ist, aber
print "Test" rgb(255 3 32) rgb 0 255 128
print "Test" rgb 255 3 32 // keine Hintergrundfarbe
eindeutig sind.
Wenn man verinnerlicht, dass der Space-Operator formal von rechts alle, auch optionalen, Argumente zur davorstehenden Funktionsbezeichnung zusammensucht, kann man damit umgehen. In komplizierten Fällen oder zur besseren Strukturierung ist es ja nicht verboten mal eine Klammer mehr zu setzen - siehe Beispiel oben!
Zu str und del:
Die gegenwärtige Struktur von str ist bereits recht vielschichtig. Die Variante (S5) im Bild zeigt aber schon eine generelle Möglichkeit der Systematisierung auf.
Ein Modus. So kann man in einer Funktion eine Gliederung vornehmen und dann auch Parameterfolgen einhalten.
z.B.
fkt(string, mod long, long, long)
oder
fkt(string, long, long [, mod long])
mit optionalem Modus.
Man bräuchte auch eine Übersicht aller wünschenswerten Grundfunktionalitäten mit etwas Blick voraus was noch dazukommen könnte/sollte/müßte. |
|
| |
| |
| |
|
|
| Klaus Hoffmeister (12.12.15)
Wenn man verinnerlicht, dass der Space-Operator formal von rechts alle, auch optionalen, Argumente zur davorstehenden Funktionsbezeichnung zusammensucht, kann man damit umgehen.
Nein, Achtung!
Das hatte ich schon einmal versucht Dir aus dem Kopf zu schlagen -
das stimmt so nicht! In Infinity kann man Funktionen beliebig überladen -
den Spaceoperator interessiert nicht wie viele Parameter eine
Funktion hat - das kann sich auch zur Laufzeit ändern durch
Neudeklaration von Procs in Procs. Er kann nur erkennen ob es eine
Funktion ist - und dann klammert er - oder ob es keine Funktion ist. |
|
| |
| |
| |
|
|
HofK | ...zusammensucht ...
Da hab ich mich nicht richtig/ zu lax ausgedrückt, im Beispiel wird aus
print "Test" rgb 255 3 32 rgb 0 255 128
print ("Test",rgb(255,3,32,rgb(0,255,128)))
es wird also von rechts zum rechten rgb geklammert und dann weiter. So meinte ich inhaltlich.
Hier gibt das sogar einen Fehler, weil dann im Endeffekt rgb(0,255,128) keine gültige Transparenz für das linke rgb ist.
Zeigt aber, dass der Operator schon auch seine Tücken hat. Trotzdem ist er gut!!! |
|
| |
| |
| |
|
|
HofK | Ergänzung zu str:
Aus Sicht des Programmierers sind im Bild oben die Varianten (S6) und (S7) von str eine Funktion mit optionalem ersten Parameter:
str([long suchAbPosition,] string Heu, string Nadel)
"Dabei ist diesmal recht ungewöhnlich der erste Parameter optional."
Dann evtl.
fkt([mod long,]string, long, long )
denkbar. |
|
| |
| |
| |
|
|
HofK | Zur neuen Struktur der Infinity-Profan Funktionen
HofK (12.12.2015)
... Ein Modus. So kann man in einer Funktion eine Gliederung vornehmen und dann auch Parameterfolgen einhalten. ...
---------------------------------------------------------------------------------------
Ergänzung zu str:
Aus Sicht des Programmierers sind im Bild oben die Varianten (S6) und (S7) von str eine Funktion mit optionalem ersten Parameter:
str([long suchAbPosition,] string Heu, string Nadel)
"Dabei ist diesmal recht ungewöhnlich der erste Parameter optional."
Dann evtl.
fkt([mod long,]string, long, long )
denkbar.
Diese Strukturierung hatte ich mir mit dem vorn stehenden Parameter etwa so gedacht. Die jetzt gewählte Punkt-Notation die man sich als assoziatives Datenfeld einer Hauptfunktion oder Hauptfunktionsobjekt vorstellen kann, ist noch übersichtlicher, besser handhabbar und bei Bedarf gut ergänzbar, solange die Schlüsselworte "passend" sind.
iF (13.01.2016)
Long modi fällt weg.
Dafür neue Funktionen:
a=arr.sort(a)
a=arr.sortnum(a)
a=arr.reverse(a)
a=arr.usort(a,fn)
Dokumentation und weitere Funktionen werden nachfolgend diesem System angepasst.
... eine Funktionsgruppe.
Die  Funktionsstruktur wird super übersichtlich / handhabbar.
Da [...]  schon gut erkennbar. |
|
| |
| |
| |
|
|
| Ok cool, bin ich froh und dankbar das Du das so siehst.
Als nächstes würde ich mich an display() (später dev.screen) herantasten, hierbei möchte ich sinngemäß etwas neues erreichen:
Getter und Setter rein über Syntax:
display.rotation(wert) <-- setter
display.rotation <-- getter
Zwar könnte man in diesem Fall als getter auch einfach display.rotation() verwenden, aber dann würde ich mir -setter ohne Parameter- stehlen.
Zudem:
device, display, gps, phone, camera, etc. wandern alle ab nach dev*,
z.B. dev.phone.call(...
Alles was also Hardware/ Sensorik oder "Module" der Geräte sind und nichts mit der Programmiersprache zu tun hat, wandert nach dev(ice).
Zudem:
Aus display wird dev.screen, damit auch Dinge wie co120 etc. darin Platz bekommen können. Genau genommen bräuchten wir dann auch kein cls und kein print mehr, wäre dann dev.screen.clear dev.screen.print - cls und print würden dann in der profan.api Platz finden. Mit Screen können dann neben den Displayfunktionen auch Grafikmodi etc. eingestellt werden und sowas wie dev.screen.screens und dev.screen.set(activeScreen) etc. passen gut zueinander/ würden.
Zudem:
Aus device wird dann schlicht dev., gibt mir auch die Möglichkeit die jetzigen Ausgaben von device() besser zu gliedern und etwa ein dev.battery herzubilden.
Noch ein Stück Arbeit, habe aber ich richtig gutes Gefühl damit nun auf dem richtigen Weg zu sein. |
|
| |
| |
| |
|
|
| Wo es mich zerreißt:
Die Geräte-Funktionen per dev(ice) etwas abzutrennen von den Funktionen der eigentlichen Programmiersprache, ergibt generell Sinn wenn ich mir dies so anschaue:
dev
dev.phone
dev.gps
dev.bluetooth
dev.camera
dev.lights
und so weiter.
So sind es auch die Funktionen, die man seltener als andere schreibt.
So gesehen wäre/n der Bildschirm/ die Bildschirme aber auch nur ein "Gerät", also wäre es dev.screen.
gui wiederum wäre der Sortierung halber dev.screen.gui -
aber dann tippt man sich ja blöde -
cls und print hätten ihren eigentlichen platz in dev.screen.clear und dev.screen.print.
Also ist die Frage, ob und nach welchen Krit. man einen Trennstrich zieht.
Meine Idee: Funktionen die man oft benötigt, gehören ins "root".
Danach würde gui unter dev.screen.gui erreichbar, aber auch im root direkt als gui. print wäre dev.screen.print und ist aber auch im root als print erreichbar. So auch cls.
So geht der Plan aber auch nicht ganz auf wenn ich mir z.B. die Funktion http ansehe da man diese auch selten schreibt und sie danach nicht ins root gehört. aber wäre es dev.http? eher dev.internet.http? und wieso überhaupt dev(ice) bei dev.http? Tja, und dann gibts auch z.B. msg - schreibt man normal auch nicht oft. dev.msg?!
So die Überlegung, ob man alles sinnvoll unter einen Hut bekommt etwa in dem "dev" umbenannt würde.
Was würde hier immer passen und kann dennoch schön kurz geschrieben werden?:
bla
bla.phone
bla.gps
bla.bluetooth
bla.camera
bla.lights
bla.screen
bla.msg
bla.internet.
Vlt. ist danach die Sortierung nach "dev." dann letztendlich doch nicht sinnvoll - und es muss auch irgendwie weiter gehen. Deshalb nehme ich dev.gps und dev.screen wieder ins root nach gps und screen. |
|
| |
| |
| |
|
|
| | Dies wäre mein jetziger Versuch alles in Einklang zu bringen: [...] |
|
| |
| |
| |
|
(850)
Deutsch
English
Français
Español
Italia