| |
| |
|
| - page 1 - |
|
 | Stark rester et par den Text.
Momentan ist es oui 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
imprimer
rgb
rnd
round
sleep
str
time
bordure
cela muss besser aller.
Klaus zeigte sur Del, et cela es pour Str pourrait.
c'est ça naturellement. Hatte je mais c'est pourquoi pas so gemacht, là str seulement ensuite une übliche Funktion (comment mid, str$, translate$...) umsetzt, si aussi qui paramètre ensuite comment chez den jeweiligen Funktionen dans üblicher Reihenfolge transfert volonté könnten.
c'est pourquoi allez
str(s,2,3) comme
mid$(s,2,3)
ou bien
str(s,f,r) comme
translate$(s,f,r)
ou bien
str(20) comme
str$(20)
chez Del était ca ensuite pas plus possible, wären qui selben paramètre comment mid:
str(s,1,2)
mid(s,1,2)
del(s,1,2)
bien sûr pourrait on eh bien:
str(1,2,s) comme
del(s,1,2) -
mais cela wäre erstmalig abweichend de einem gewissen Standard.
tout autor J'ai eu del einzeln. So aussi chez anderen Funktionen.
suis mais pas zufrieden.
concept: Bessere Schlüsselworte.
Beispiel:
il y a len et width et fattr pour filesize.
pourquoi pas seulement len ou bien width, len ou bien width sur un file pourrait filesize donner.
mais width(file)? Ist doch Murx, aussi len(FILE file) ist Murx.
Width("Hallo") pourrait naturellement 5 son.
pourquoi alors pas simple une Funktion size et ne...aucune width plus et ne...aucune len.
imprimer size(string "Hallo")
imprimer size(file "/...")
imprimer size(display) /// pourrait un array ergeben [xx,yy,"width"=xx,"height"=yy]
Pratiquement un encore ultra kompakterer Sprachkern.
s'il te plaît aucun «Est- pas übersichtlich"- Hinweise, car cela quoi je mon, soll besser et übersichtlicher son comme Basic.
Experiment:
del
get
set
dir
file
float
int
string
copy
device
display
exec
gps
gui
http
msg
phone
imprimer
rgb
rnd
round
size
sleep
time
bordure
abschaffbar là theoretisch rein par syntax herbildbar
arr
-
cela wären ensuite 25 Befehle statt 32 et avec cela wäre eindeutiger ableitbar.
am beispiel:
file del f //fdel
file set f s //fwrite
file get f //fread
file size s
aussi kürzer mgl:
file del f
file f s
file f
file size f
alors statt fread,fwrite,filesize,fdel seulement encore allgemeinere Schlüsselworte: file, del set get size - Schlüsselworte qui wiederum aussi dans den anderen Befehlen verwendet volonté könnten.
Ist arrêt un Gedankenexperiment.
l'autre variante ist qui XProfane ou bien encore exzessiver comment chez PHP: Ultra-viele-Befehle en Namen déjà assez bien en Funktion décrire. quelque chose comme comment createImageFromPng etc.
mais peut-être bekommen wir oui cela genaue Gegenteil hin et bieten qui Langbefehlsnamen ensuite per XProfan.api.
je mon, si pas maintenant trop Beginn qui Entwicklung qui Discours, quand ensuite solche Überlegungen... |
|
| |
| |
| |
|
|
| |
| |
| - page 1 - |
|
HofK | là beißen sich ensuite deux Dinge encore kräftiger, qui aussi maintenant déjà un Problem sommes.
Momentan alors qui variable Parameteranzahl et qui Deutung par den Space-Operator.
sur den voudrais je mais pas plus verzichten, aussi si plan chez
imprimer "Test" rgb(255 3 32) rgb( 0 255 128) // une Klammer pourrait encore wegfallen
qui Klammern pas plus beide entfallen peut, là qui Tranzparenz "im Wege" ist, mais
imprimer "Test" rgb(255 3 32) rgb 0 255 128
imprimer "Test" rgb 255 3 32 // aucun Hintergrundfarbe
sans équivoque sommes.
si on verinnerlicht, dass qui Space-Operator formal de à droite alle, aussi optionalen, Argumente zur davorstehenden Funktionsbezeichnung zusammensucht, peux on avec cela tourner autour de. dans komplizierten Fällen ou bien zur besseren Strukturierung ist es oui pas interdit la fois une Klammer plus trop mettons - siehe Beispiel dessus!
trop str et del:
qui gegenwärtige Struktur de str ist bereits droite vielschichtig. qui variante (S5) im Bild zeigt mais déjà une generelle Possibilité qui Systematisierung sur.
un Modus. So peux on dans einer Funktion une Gliederung vornehmen et ensuite aussi Parameterfolgen einhalten.
z.B.
fkt(string, mod long, long, long)
ou bien
fkt(string, long, long [, mod long])
avec optionalem Modus.
on bräuchte aussi une Vue d'ensemble aller wünschenswerten Grundfunktionalitäten avec quelque chose perspective voraus quoi encore dazukommen pourrait/sollte/devrait. |
|
| |
| |
| |
|
|
| Klaus Hoffmeister (12.12.15)
si on verinnerlicht, dass qui Space-Operator formal de à droite alle, aussi optionalen, Argumente zur davorstehenden Funktionsbezeichnung zusammensucht, peux on avec cela tourner autour de.
non, attention!
cela J'ai eu déjà einmal versucht Dir aus dem tête trop schlagen -
c'est ça so pas! dans Infinity peux on Funktionen beliebig überladen -
den Spaceoperator intéressé pas comment viele paramètre une
Funktion hat - cela peux sich aussi zur Laufzeit changement par
Neudeklaration de Procs dans Procs. il peut seulement erkennen si es une
Funktion ist - et ensuite klammert il - ou bien si es aucun Funktion ist. |
|
| |
| |
| |
|
|
HofK | ...zusammensucht ...
là hab je mich pas richtig/ trop lax ausgedrückt, im Beispiel wird aus
imprimer "Test" rgb 255 3 32 rgb 0 255 128
imprimer ("Test",rgb(255,3,32,rgb(0,255,128)))
es wird alors de à droite zum rechten rgb geklammert et ensuite plus. So meinte je inhaltlich.
ici gibt cela sogar une faute, weil ensuite im Endeffekt rgb(0,255,128) aucun gültige Transparenz pour cela linke rgb ist.
Zeigt mais, dass qui Operator déjà aussi sa Tücken hat. quand même ist il bien!!! |
|
| |
| |
| |
|
|
HofK | Ergänzung trop str:
Aus Sicht des Programmierers sommes im Bild dessus qui Varianten (S6) et (S7) de str une Funktion avec optionalem ersten paramètre:
str([long suchAbPosition,] string Heu, string aiguille)
"Dabei ist diesmal droite ungewöhnlich qui erste paramètre optionnel."
ensuite peut-être.
fkt([mod long,]string, long, long )
imaginable. |
|
| |
| |
| |
|
|
HofK | Zur neuen Struktur qui Infinity-Profan Funktionen
HofK (12.12.2015)
... un Modus. So peux on dans einer Funktion une Gliederung vornehmen et ensuite aussi Parameterfolgen einhalten. ...
---------------------------------------------------------------------------------------
Ergänzung trop str:
Aus Sicht des Programmierers sommes im Bild dessus qui Varianten (S6) et (S7) de str une Funktion avec optionalem ersten paramètre:
str([long suchAbPosition,] string Heu, string aiguille)
"Dabei ist diesmal droite ungewöhnlich qui erste paramètre optionnel."
ensuite peut-être.
fkt([mod long,]string, long, long )
imaginable.
cet Strukturierung J'ai eu mir avec dem vorn stehenden paramètre etwa so gedacht. qui maintenant gewählte Punkt-Notation qui on sich comme assoziatives Datenfeld einer Hauptfunktion ou bien Hauptfunktionsobjekt présenter peux, ist encore übersichtlicher, besser handhabbar et chez besoin bien ergänzbar, solange qui Schlüsselworte "passend" sommes.
iF (13.01.2016)
Long modi fällt weg.
Pour cette neue Funktionen:
a=arr.sort(a)
a=arr.sortnum(a)
a=arr.reverse(a)
a=arr.usort(a,fn)
Documentation et weitere Funktionen volonté nachfolgend diesem System angepasst.
... une Funktionsgruppe.
qui  Funktionsstruktur wird super übersichtlich / handhabbar.
là [...]  déjà bien erkennbar. |
|
| |
| |
| |
|
|
| Ok cool, suis je froh et reconnaissant cela Du cela so vois.
comme nächstes serait je mich à display() (später dev.screen) herantasten, hierbei voudrais je sinngemäß quelque chose nouveau erreichen:
Getter et Setter rein sur Syntax:
display.rotation(wert) <-- setter
display.rotation <-- getter
Zwar pourrait on dans diesem le cas comme getter aussi simple display.rotation() verwenden, mais ensuite serait je mir -setter sans paramètre- stehlen.
Zudem:
device, display, gps, phone, camera, etc. wandern alle ab pour dev*,
z.B. dev.phone.call(...
Alles quoi alors Hardware/ Sensorik ou bien "Module" qui Geräte sommes et rien avec qui Programmiersprache trop 1faire hat, wandert pour dev(ice).
Zudem:
Aus display wird dev.screen, avec cela aussi Dinge comment co120 etc. y place bekommen peut. oui c'est ca pris bräuchten wir ensuite aussi ne...aucune cls et ne...aucune imprimer plus, wäre ensuite dev.screen.clear dev.screen.imprimer - cls et imprimer würden ensuite dans qui profan.api place trouver. avec Screen peut ensuite près de den Displayfunktionen aussi Grafikmodi etc. eingestellt volonté et quelque chose comme comment dev.screen.screens et dev.screen.set(activeScreen) etc. passen bien zueinander/ würden.
Zudem:
Aus device wird ensuite schlicht dev., gibt mir aussi qui Possibilité qui jetzigen Ausgaben de device() besser trop gliedern et etwa un dev.battery herzubilden.
encore un Stück travail, habe mais je richtig gutes sentiment avec cela eh bien sur dem richtigen Weg trop son. |
|
| |
| |
| |
|
|
| wohin es mich zerreißt:
qui Geräte-Funktionen per dev(ice) quelque chose abzutrennen de den Funktionen qui réel Programmiersprache, ergibt generell Sinn si je mir ca so anschaue:
dev
dev.phone
dev.gps
dev.bluetooth
dev.camera
dev.lights
et so plus.
So sommes es aussi qui Funktionen, qui on seltener comme autre écrit.
So gesehen wäre/n qui Bildschirm/ qui Bildschirme mais aussi seulement un "Gerät", alors wäre es dev.screen.
gui wiederum wäre qui Sortierung halber dev.screen.gui -
mais ensuite tippt on sich oui blöde -
cls et imprimer hätten ihren réel place dans dev.screen.clear et dev.screen.imprimer.
alors ist qui Frage, si et pour welchen Krit. on une Trennstrich zieht.
mon concept: Funktionen qui on souvent nécessaire, gehören ins "root".
après serait gui sous dev.screen.gui erreichbar, mais aussi im racine direct comme gui. imprimer wäre dev.screen.imprimer et ist mais aussi im racine comme imprimer erreichbar. So aussi cls.
So allez qui plan mais aussi pas entier sur si je mir z.B. qui Funktion http ansehe là on cet aussi selten écrit et vous après pas ins racine est. mais wäre es dev.http? plutôt dev.internet.http? et wieso überhaupt dev(ice) chez dev.http? Tja, et ensuite gibts aussi z.B. msg - écrit on normal aussi pas souvent. dev.msg?!
So qui Überlegung, si on alles sinnvoll sous une Hut bekommt etwa dans dem "dev" umbenannt serait.
quoi serait ici toujours passen et peux toutefois joli kurz geschrieben volonté?:
bla
bla.phone
bla.gps
bla.bluetooth
bla.camera
bla.lights
bla.screen
bla.msg
bla.internet.
Vlt. ist après qui Sortierung pour "dev." ensuite letztendlich doch pas sinnvoll - et es muss aussi irgendwie continuer. c'est pourquoi nehme je dev.gps et dev.screen wieder ins racine pour gps et screen. |
|
| |
| |
| |
|
|
| | ca wäre mon jetziger Versuch alles dans Einklang trop apporter: [...] |
|
| |
| |
| |
|
| |
| |
| - page 2 - |
|
|
HofK | cet Dialemma hat on eigentlich toujours plus ou bien moins dans den Sprachen et si je imprimer quelquefois pas joli finde, ist printf encore schlimmer si es ne...aucune imprimer gibt. mais encore droite kurz et on gewöhnt sich daran.
mais qui öfter soetwas comment
GridLayout gl = (GridLayout) findViewById(R.id.GridLayout1);
écrivons darf et déjà denkt, dass il stottert, ist pas verwöhnt.
dans den objektorientierten Sprachen allez on oui aussi une Konmpromiss un. quoique es un Integer objet gibt, peux on là wenigstens partiellement et avec ca vereinfacht notieren. Sonst wäre es entier grave. chez file et arr sommes es droite eng umrissene Bereiche, cela Problem entsteht, si qui Bereich unscharf et trop grand wird et sich Überlappungen ergeben et plan chez "Basisfunktionen".
Device ist im Sinne qui Programmation un peut-être viel trop umfassender Oberbegriff. [...] qui Funktionsnamen avec Untergruppe sommes ensuite doch droite long.
dev.screen.gui
dev.screen.gui.msg
partage déjà de qui l'affaire her sinnvoll, z.B etwa dans qui Art
Bildschirm: scr
là eigentlich central Graphical User Interface: gui
clavier: kbd
caméra: camera
Verbindungen: com
Sensoren/Effektoren: sensor
Weitere "Gedanken":
si fktgrpbsp une FunKTionsGRuPpe BeiSPiel ist, ensuite volonté qui Funktionen per
fktgrpbsp.fkta
fktgrpbsp.fktb
angesprochen et qui fkta, fktb doit eigentlich seulement dans qui Gruppe sans équivoque son.
c'est mais sûrement pas hilfreich dans verschiedenen Gruppen gleiche Funktionsbezeichnungen trop avons.
qui Basisfunktionen (racine) qui on üblicherweise presque dans chaque Programme écrit sommes sûrement sans équivoque et könnten theoretisch simple so notiert volonté.
ou bien une kurze Kennung?
comme Kennung pour qui Basisfunktionen venez racine. à peine dans Frage, viel trop long et pas entier unmissverständlich.
bla. hat trois Buchstaben, kürzer ist à peine possible allez mais wohl pas du tout.
entier omettre gäbe seulement den Punkt. cela pourrait peut-être syntaktische Probleme donner ou bien on vergißt den Punkt häufig.
.cls
.gui
ou bien es findet sich wieder la fois un geniales racine-Sonderzeichen?
@ wurde justement "verbraten", avec ~ J'ai eu déjà la fois une autre concept sur le lit. là bleibt pas viel. §cls, §gui §print comme mir aussi pas wirklich.
l'autre angedeutete Possibilité (racine) technique so betrachtet:
qui Basisfunktionen generell comme Funktionsgruppe avec einer einzigen Funktion?
cls.cls peux ensuite z.B. mais aussi kurz seulement cls geschrieben volonté, sonst pouvoir es keinen Sinn.
Am schwierigsten wird wohl qui sélection qui prädestinierten Funktionen, avec cela qui l'affaire avec den Funktionsgruppen aussi ihren réel Sinn behält. |
|
| |
| |
| |
|
|
HofK | Ergänzung:
justement si je mir gui avec seinen Funktionalitäten so ansehe (là venons encore quelle comment draw usw. en supplément) ist
dev.screen.gui.text et ensuite qui ganzen paramètre
dev.screen.gui.grid et ensuite qui ganzen paramètre [...]
aucun perfekte Solution si je mir mon bisherigen Beispiele so anschaue. un größeres gui-Dings trop gestalten peux ensuite embêtant volonté. |
|
| |
| |
| |
|
|
| Nene aucun Sorge,
qui souvent-Genutzen bekommen oui un alias ins racine -
so ist gui technique aussi sous dev.screen.gui abrufbar mais toutefois simple sur gui. So wirds ensuite gui.grid donner etc.
mais im Gegenvergleich en supplément nehme je http aus dem racine, es reicht dans dev.internet.http - weils aucun Funktion ist qui on souvent écrit sodass vous un alias im racine verdient hätte. |
|
| |
| |
| |
|
|
HofK | avec Alias voll ok. 
Bleibt qui Überlegung, si qui Gruppe device wirklich aussi grand son sollte. Eigentlich ist oui mon ganzes Phone velours Anbindung mon Device.
mais c'est, égal comme wird, viel besser comme manche idées de "den Großen":
-------------------------------------------------------------------
Eigentlich stört mich chez dem dessus erwähnten
GridLayout gl = (GridLayout) findViewById(R.id.GridLayout1);
oui une entier autre l'affaire.
comme je avec cela anfing, était mon idée: quoi s'il te plaît ist cela mikrige R là 
Muss assez sans signification ou bien gaaanz important son.
Hab's herausgefunden, eigentlich devrait statt des simplen R.id.GridLayout1 réglé
app.resources.layout.activity_main.GridLayout.android:id="@+id/GridLayout1"
ou bien so ähnlich stehen. ensuite wäre qui Programmzeile en tout aussi imposanter et on hätte plus vénération avant Android Java.
oui, beim resources hat on aussi encore gegeizt et seulement trois Buchstaben spendiert, mais qui Unterpunkt drawable ist oui pour pas zum drw gekürzt! on ist um Ausgleich prêt.
Über Syntax peux on toujours fachsimpeln, cela Thema ist ergiebig comment cela Wetter. |
|
| |
| |
| |
|
(487)
Deutsch
English
Français
Español
Italia