| |
| |
|
| - Page 1 - |
|
 | 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 potuto.
Das stimmt naturalmente. 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 trasferimento 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 possibile, wären die selben Parameter wie mid:
str(s,1,2)
mid(s,1,2)
del(s,1,2)
klar potuto 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 per filesize.
warum nicht nur len oder width, len oder width auf ein file potuto filesize geben.
Aber width(file)? Ist doch Murx, auch len(FILE file) ist Murx.
Width("Hallo") potuto naturalmente 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) /// potuto 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... |
|
| |
| |
| |
|
|
| |
| |
| - Page 1 - |
|
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 potuto 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 Panoramica aller wünschenswerten Grundfunktionalitäten mit etwas Blick voraus was noch dazukommen potuto/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 per 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)
Documentazione 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 circa Syntax:
display.rotation(wert) <-- setter
display.rotation <-- getter
Zwar potuto 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 necessario, 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: [...] |
|
| |
| |
| |
|
| |
| |
| - Page 2 - |
|
|
HofK | Dieses Dialemma hat man eigentlich immer mehr oder weniger in den Sprachen und wenn ich print manchmal nicht schön finde, ist printf noch schlimmer wenn es kein print gibt. Aber noch recht kurz und man gewöhnt sich daran.
Aber wer öfter soetwas wie
GridLayout gl = (GridLayout) findViewById(R.id.GridLayout1);
schreiben darf und schon denkt, dass er stottert, ist nicht verwöhnt.
In den objektorientierten Sprachen geht man ja auch einen Konmpromiss ein. Obwohl es ein Integer Objekt gibt, kann man da wenigstens teilweise noch etwas vereinfacht notieren. Sonst wäre es ganz schlimm. Bei file und arr sind es recht eng umrissene Bereiche, das Problem entsteht, wenn der Bereich unscharf und zu grande wird und sich Überlappungen ergeben und eben bei "Basisfunktionen".
Device ist im Sinne der Programmazione ein vielleicht viel zu umfassender Oberbegriff. [...] Die Funktionsnamen mit Untergruppe sind dann doch recht lang.
dev.screen.gui
dev.screen.gui.msg
Teilung schon von der Sache her sinnvoll, z.B etwa in der Art
Bildschirm: scr
Da eigentlich zentral Graphical User Interface: gui
Tastatur: kbd
Kamera: camera
Verbindungen: com
Sensoren/Effektoren: sensor
Weitere "Gedanken":
Wenn fktgrpbsp eine FunKTionsGRuPpe BeiSPiel ist, dann werden die Funktionen per
fktgrpbsp.fkta
fktgrpbsp.fktb
angesprochen und die fkta, fktb müssen eigentlich nur in der Gruppe eindeutig sein.
Es ist aber sicher nicht hilfreich in verschiedenen Gruppen gleiche Funktionsbezeichnungen zu haben.
Die Basisfunktionen (root) die man üblicherweise fast in jedem Programm schreibt sind sicher eindeutig und könnten theoretisch einfach so notiert werden.
Oder eine kurze Kennung?
Als Kennung per die Basisfunktionen kommt root. kaum in Frage, viel zu lang und auch nicht ganz unmissverständlich.
bla. hat drei Buchstaben, kürzer ist kaum possibile geht aber wohl überhaupt nicht.
Ganz weglassen gäbe nur den Punkt. Das potuto vielleicht syntaktische Probleme geben oder man vergißt den Punkt häufig.
.cls
.gui
Oder es findet sich wieder mal ein geniales root-Sonderzeichen?
@ wurde gerade "verbraten", mit ~ hatte ich schon mal eine andere Idee auf Lager. Da bleibt nicht viel. §cls, §gui §print gefällt mir auch nicht wirklich.
Die andere angedeutete Möglichkeit (root) technisch so betrachtet:
Die Basisfunktionen generell als Funktionsgruppe mit einer einzigen Funktion?
cls.cls kann dann z.B. aber auch kurz nur cls geschrieben werden, sonst macht es keinen Sinn.
Am schwierigsten wird wohl die Auswahl der prädestinierten Funktionen, damit die Sache mit den Funktionsgruppen auch ihren eigentlichen Sinn behält. |
|
| |
| |
| |
|
|
HofK | Ergänzung:
Gerade wenn ich mir gui mit seinen Funktionalitäten so ansehe (da kommen noch welche wie draw usw. dazu) ist
dev.screen.gui.text und dann die ganzen Parameter
dev.screen.gui.grid und dann die ganzen Parameter [...]
keine perfekte Lösung wenn ich mir meine bisherigen Beispiele so anschaue. Ein größeres gui-Dings zu gestalten kann dann lästig werden. |
|
| |
| |
| |
|
|
| Nene keine Sorge,
die oft-Genutzen bekommen ja ein alias ins root -
so ist gui technisch auch unter dev.screen.gui abrufbar aber dennoch einfach circa gui. So wirds dann gui.grid geben etc.
Aber im Gegenvergleich dazu nehme ich http aus dem root, es reicht in dev.internet.http - weils keine Funktion ist die man oft schreibt sodass sie ein alias im root verdient hätte. |
|
| |
| |
| |
|
|
HofK | Mit Alias voll ok. 
Bleibt die Überlegung, ob die Gruppe device wirklich so grande sein sollte. Eigentlich ist ja mein ganzes Phone samt Anbindung mein Device.
Aber es ist, egal wie es wird, viel besser als manche Ideen von "den Großen":
-------------------------------------------------------------------
Eigentlich stört mich bei dem oben erwähnten
GridLayout gl = (GridLayout) findViewById(R.id.GridLayout1);
ja eine ganz andere Sache.
Als ich damit anfing, war mein Gedanke: Was bitte ist das mikrige R da 
Muss ziemlich bedeutungslos oder gaaanz wichtig sein.
Hab's herausgefunden, eigentlich müsste statt des simplen R.id.GridLayout1 ordentlich
app.resources.layout.activity_main.GridLayout.android:id="@+id/GridLayout1"
oder so ähnlich stehen. Dann wäre die Programmzeile insgesamt auch imposanter und man hätte mehr Ehrfurcht vor Android Java.
Ja, beim resources hat man auch noch gegeizt und nur drei Buchstaben spendiert, aber der Unterpunkt drawable ist ja dafür nicht zum drw gekürzt! Man ist um Ausgleich bemüht.
Über Syntax kann man immer fachsimpeln, das Thema ist ergiebig wie das Wetter. |
|
| |
| |
| |
|
(454)
Deutsch
English
Français
Español
Italia