| |
| |
|
| - Página 1 - |
|
 | Stark bleiben y por el Texto.
Momentan es sí así:
arr
chdir
chr
cls
del
device
display
event
exec
fattr
fcopy
fdel
float
fread
fwrite
gps
gui
http
len
long
math
msg
ord
phone
imprimir
rgb
rnd
round
sleep
str
time
trim
Das muss mejor ir.
Klaus zeigte en Del, y el lo después de Str podría.
Das stimmt natürlich. Hatte Yo aber deshalb no así gemacht, como str sólo entonces una übliche Función (como mid, str$, translate$...) umsetzt, si auch el Parámetro entonces como en el jeweiligen Características en üblicher Reihenfolge transferencia voluntad könnten.
Deshalb va
str(s,2,3) como
mid$(s,2,3)
oder
str(s,f,r) como
translate$(s,f,r)
oder
str(20) como
str$(20)
en Del war dies entonces no mehr posible, wären el selben Parámetro como mid:
str(s,1,2)
mid(s,1,2)
del(s,1,2)
klar podría uno nun:
str(1,2,s) como
del(s,1,2) -
aber el wäre erstmalig abweichend de una gewissen Standard.
Darum Tuve del einzeln. So auch en otro Características.
Bin pero no zufrieden.
Concepto: Bessere Schlüsselworte.
Ejemplo:
lo son len y width y fattr para filesize.
por qué no sólo len oder width, len oder width en una file podría filesize geben.
Aber width(file)? Ist doch Murx, auch len(FILE file) es Murx.
Width("Hallo") podría natürlich 5 ser.
¿Por qué also no simplemente una Función size y kein width mehr y kein len.
imprimir size(cadena "Hallo")
imprimir size(file "/...")
imprimir size(display) /// podría una array ergeben [xx,yy,"width"=xx,"height"=yy]
Quasi una todavía ultra kompakterer Sprachkern.
Bitte no "ist no übersichtlich"- Hinweise, porque el Yo mi, se mejor y übersichtlicher ser como Basic.
Experiment:
del
get
set
dir
file
float
int
cadena
copy
device
display
exec
gps
gui
http
msg
phone
imprimir
rgb
rnd
round
size
sleep
time
trim
abschaffbar como theoretisch rein por syntax herbildbar
arr
-
el wären entonces 25 Befehle en lugar de 32 y así wäre eindeutiger ableitbar.
al 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 en lugar de fread,fwrite,filesize,fdel sólo todavía allgemeinere Schlüsselworte: file, del set get size - Schlüsselworte el wiederum auch en el otro Befehlen verwendet voluntad könnten.
Ist sólo una Gedankenexperiment.
El otro Variante Es el XProfane oder todavía exzessiver como en PHP: Ultra-viele-Befehle deren Namen ya bastante bien deren Función beschreiben. algo como como createImageFromPng etc.
Aber tal vez bekommen wir sí el genaue Gegenteil hin y bieten el Langbefehlsnamen entonces por XProfan.api.
Yo mi, si no ahora a Beginn el desarrollo la lengua, wann entonces solche Überlegungen... |
|
| |
| |
| |
|
|
| |
| |
| - Página 1 - |
|
HofK | Como beißen se entonces zwei Dinge todavía kräftiger, el auch ahora ya una Problema son.
Momentan Así que el variable Parameteranzahl y el Deutung por el Espacio-Operator.
Auf el möchte Yo pero no mehr verzichten, auch si eben en
imprimir "Test" rgb(255 3 32) rgb( 0 255 128) // una Klammer podría todavía wegfallen
el Klammern no mehr beide entfallen puede, como el Tranzparenz "im Wege" es, aber
imprimir "Test" rgb(255 3 32) rgb 0 255 128
imprimir "Test" rgb 255 3 32 // no Color de fondo
eindeutig son.
Wenn uno verinnerlicht, dass el Espacio-Operator formal de rechts todos, auch optionalen, Argumente a davorstehenden Funktionsbezeichnung zusammensucht, puede ser así umgehen. In komplizierten Fällen oder a mejor Strukturierung es sí no verboten veces una Klammer mehr a conjunto - siehe Ejemplo oben!
Zu str y del:
El gegenwärtige Struktur de str es ya bastante vielschichtig. El Variante (S5) en el Bild zeigt aber ya una generelle Möglichkeit el Systematisierung en.
Ein Modus. So puede ser en uno Función una Gliederung vornehmen y luego auch Parameterfolgen einhalten.
por ejemplo
fkt(cadena, mod long, long, long)
oder
fkt(cadena, long, long [, mod long])
con optionalem Modus.
Man bräuchte auch una Información general aller wünschenswerten Grundfunktionalitäten con algo Blick voraus qué todavía dazukommen podría/debería/müßte. |
|
| |
| |
| |
|
|
| Klaus Hoffmeister (12.12.15)
Wenn uno verinnerlicht, dass el Espacio-Operator formal de rechts todos, auch optionalen, Argumente a davorstehenden Funktionsbezeichnung zusammensucht, puede ser así umgehen.
Nein, Achtung!
Das Tuve ya una vez intenta Usted de el Kopf a schlagen -
el stimmt así no! In Infinity puede ser Características cualquier überladen -
el Spaceoperator interessiert no como viele Parámetro una
Función ha - el kann se auch a Laufzeit ändern por
Neudeklaration de Procs en Procs. Er kann sólo erkennen si una
Función es - y luego klammert él - oder si no Función es. |
|
| |
| |
| |
|
|
HofK | ...zusammensucht ...
Como tener Yo mich no correcto/ a lax ausgedrückt, en el Ejemplo se de
imprimir "Test" rgb 255 3 32 rgb 0 255 128
imprimir ("Test",rgb(255,3,32,rgb(0,255,128)))
lo se also de rechts para rechten rgb geklammert y luego más. So meinte Yo inhaltlich.
Hier son el incluso una Fehler, porque entonces en el Endeffekt rgb(0,255,128) no gültige Transparenz para el linke rgb es.
Espectáculos aber, dass el Operator ya auch seine Tücken ha. Trotzdem es él bien!!! |
|
| |
| |
| |
|
|
HofK | Ergänzung a str:
Aus Sicht des Programmierers son en el Bild oben el Varianten (S6) y (S7) de str una Función con optionalem ersten Parámetro:
str([long suchAbPosition,] cadena Heu, cadena Nadel)
"Dabei es diesmal bastante ungewöhnlich el erste Parámetro optional."
Dann evtl.
fkt([mod long,]cadena, long, long )
denkbar. |
|
| |
| |
| |
|
|
HofK | A neuen Struktur el Infinity-Profano Características
HofK (12.12.2015)
... Ein Modus. So puede ser en uno Función una Gliederung vornehmen y luego auch Parameterfolgen einhalten. ...
---------------------------------------------------------------------------------------
Ergänzung a str:
Aus Sicht des Programmierers son en el Bild oben el Varianten (S6) y (S7) de str una Función con optionalem ersten Parámetro:
str([long suchAbPosition,] cadena Heu, cadena Nadel)
"Dabei es diesmal bastante ungewöhnlich el erste Parámetro optional."
Dann evtl.
fkt([mod long,]cadena, long, long )
denkbar.
Diese Strukturierung Tuve me con el vorn stehenden Parámetro etwa así pensamiento. El ahora gewählte Punkt-Notation el uno se como assoziatives Datenfeld uno Hauptfunktion oder Hauptfunktionsobjekt vorstellen kann, es todavía übersichtlicher, mejor handhabbar y en Bedarf bien ergänzbar, solange el Schlüsselworte "passend" son.
IF (13.01.2016)
Largo modi fällt weg.
Dafür neue Características:
a=arr.sort(a)
a=arr.sortnum(a)
a=arr.reverse(a)
a=arr.usort(a,fn)
Documentación y weitere Características voluntad nachfolgend diesem Sistema adaptado.
... una Funktionsgruppe.
El  Funktionsstruktur se super übersichtlich / handhabbar.
Como [...]  ya bien erkennbar. |
|
| |
| |
| |
|
|
| Ok fresco, bin Yo froh y dankbar el Usted el así siehst.
Als nächstes sería Yo mich a display() (später dev.screen) herantasten, hierbei möchte Yo sinngemäß algo neues erreichen:
Getter y Setter rein encima Syntax:
display.rotation(wert) <-- setter
display.rotation <-- getter
Zwar podría uno en diesem Fall como getter auch simplemente display.rotation() uso, aber Yo me -setter sin Parámetro- stehlen.
Zudem:
device, display, gps, phone, camera, etc. wandern todos de después de dev*,
z.B. dev.phone.call(...
Alles qué also Hardware/ Sensorik oder "Module" el Geräte son y nichts con el Lenguaje de programación a tun ha, wandert después de dev(ice).
Zudem:
Aus display se dev.screen, así auch Dinge como co120 etc. en él Platz bekommen puede. Exactamente genommen bräuchten wir entonces auch kein cls y kein imprimir mehr, wäre entonces dev.screen.clear dev.screen.imprimir - cls y imprimir würden entonces en el profano.api Platz encontrar. Mit Screen puede entonces neben el Displayfunktionen auch Grafikmodi etc. eingestellt y ser algo como como dev.screen.screens y dev.screen.set(activeScreen) etc. passen bien zueinander/ würden.
Zudem:
Aus device se entonces schlicht dev., son me auch el Möglichkeit el jetzigen Ausgaben de device() mejor a gliedern y etwa una dev.battery herzubilden.
Noch una Stück Arbeit, habe pero yo correcto gutes Gefühl así nun en el richtigen Weg a ser. |
|
| |
| |
| |
|
|
| Wo lo mich zerreißt:
El Geräte-Características por dev(ice) algo abzutrennen de los Características el real Lenguaje de programación, ergibt generell Sinn si yo me dies así anschaue:
dev
dev.phone
dev.gps
dev.bluetooth
dev.camera
dev.lights
y así más.
So son lo auch el Características, el uno seltener como otro schreibt.
So gesehen wäre/n el Bildschirm/ el Bildschirme aber auch sólo una "Gerät", also wäre lo dev.screen.
gui wiederum wäre el Sortierung halber dev.screen.gui -
aber entonces tippt uno se sí blöde -
cls y imprimir hätten ihren real platz en dev.screen.clear y dev.screen.imprimir.
Also Es el Cuestión, si y después de welchen Krit. uno una Trennstrich zieht.
Mi Concepto: Características el uno oft benötigt, gehören en el "root".
Danach sería gui bajo dev.screen.gui erreichbar, aber auch en el root direkt como gui. imprimir wäre dev.screen.imprimir y es aber auch en el root como imprimir erreichbar. So auch cls.
So va el Plan aber auch no bastante en si yo me z.B. el Función http ansehe como uno esta auch selten schreibt y ellos danach no en el root gehört. aber wäre lo dev.http? más dev.internet.http? y wieso überhaupt dev(ice) en dev.http? Tja, y luego gibts auch z.B. msg - schreibt uno normal auch no oft. dev.msg?!
So el Überlegung, si uno alles sinnvoll bajo una Hut bekommt etwa en el "dev" umbenannt sería.
Was sería hier siempre passen y kann todavía schön kurz geschrieben voluntad?:
bla
bla.phone
bla.gps
bla.bluetooth
bla.camera
bla.lights
bla.screen
bla.msg
bla.internet.
Vlt. es danach el Sortierung después de "dev." entonces letztendlich doch no sinnvoll - y lo muss auch irgendwie más ir. Deshalb Aprovecho dev.gps y dev.screen otra vez en el root después de gps y screen. |
|
| |
| |
| |
|
|
| | Dies wäre mein jetziger Intento alles en Einklang a bringen: [...] |
|
| |
| |
| |
|
| |
| |
| - Página 2 - |
|
|
HofK | Dieses Dialemma ha uno eigentlich siempre o más weniger en el Lenguajes y si yo imprimir manchmal no schön finde, es printf todavía schlimmer si kein imprimir son. Aber todavía bastante kurz y uno gewöhnt se daran.
Aber wer öfter soetwas como
GridLayout gl = (GridLayout) findViewById(R.id.GridLayout1);
escribir darf y ya denkt, dass él stottert, es no verwöhnt.
In el objektorientierten Idiomas va uno en efecto una Konmpromiss una. Obwohl lo una Integer El objeto está, puede ser como wenigstens teilweise todavía algo vereinfacht notieren. Sonst wäre lo bastante schlimm. En file y arr son lo bastante eng umrissene Bereiche, el problema entsteht, si la Zona unscharf y a groß se y se Überlappungen ergeben y eben en "Basisfunktionen".
Device es en el Sinne el Programación una tal vez viel a umfassender Oberbegriff. [...] El Funktionsnamen con Untergruppe son entonces doch bastante lang.
dev.screen.gui
dev.screen.gui.msg
Teilung ya de el Sache her sinnvoll, z.B etwa en el Art
Bildschirm: scr
Como eigentlich zentral Graphical User Interface: gui
Tastatur: kbd
Kamera: camera
Verbindungen: com
Sensoren/Effektoren: sensor
Weitere "Gedanken":
Wenn fktgrpbsp una FunKTionsGRuPpe BeiSPiel es, entonces voluntad el Características por
fktgrpbsp.fkta
fktgrpbsp.fktb
angesprochen y el fkta, fktb necesario eigentlich sólo en el Gruppe eindeutig ser.
Es aber sicher no hilfreich en verschiedenen Gruppen gleiche Funktionsbezeichnungen a haben.
El Basisfunktionen (root) el uno üblicherweise fast en cada Programa schreibt son sicher eindeutig y könnten theoretisch simplemente así notiert voluntad.
Oder una kurze Kennung?
Als Kennung para el Basisfunktionen kommt root. kaum en Cuestión, viel a lang y no bastante unmissverständlich.
bla. ha drei Buchstaben, kürzer es kaum posible va pero probablemente überhaupt no.
Ganz weglassen gäbe sólo el Punkt. Das podría tal vez syntaktische Problemas geben oder uno vergißt el Punkt häufig.
.cls
.gui
Oder lo findet se otra vez veces una geniales root-Sonderzeichen?
@ wurde gerade "verbraten", con ~ Tuve ya veces una otro Concepto en Lager. Como restos no viel. §cls, §gui §print gefällt me auch no wirklich.
El otro angedeutete Möglichkeit (root) technisch así betrachtet:
El Basisfunktionen generell como Funktionsgruppe con uno einzigen Función?
cls.cls kann entonces z.B. aber también brevemente sólo cls geschrieben voluntad, sonst macht lo no Sinn.
Am schwierigsten probablemente el Auswahl el prädestinierten Características, así el Sache con el Funktionsgruppen auch ihren real Sinn behält. |
|
| |
| |
| |
|
|
HofK | Ergänzung:
Gerade si yo me gui con seinen Funktionalitäten así ansehe (como kommen todavía welche como draw usw. dazu) es
dev.screen.gui.texto y luego el ganzen Parámetro
dev.screen.gui.grid y luego el ganzen Parámetro [...]
no perfekte Solución si yo me mi reciente Beispiele así anschaue. Ein größeres gui-Dings a gestalten kann entonces lästig voluntad. |
|
| |
| |
| |
|
|
| Nene no Sorge,
el oft-Genutzen bekommen sí una alias en el root -
así es gui technisch auch bajo dev.screen.gui abrufbar aber todavía simplemente encima gui. So Será mejor que te va entonces gui.grid geben etc.
Aber en el Gegenvergleich dazu Aprovecho http de el root, lo reicht en dev.internet.http - weils no Función Es el uno oft schreibt sodass ellos una alias en el root verdient hätte. |
|
| |
| |
| |
|
|
HofK | Mit Alias voll ok. 
Bleibt el Überlegung, si el Gruppe device wirklich así groß ser debería. Eigentlich es sí mein ganzes Phone samt Anbindung mein Device.
Aber es, egal como se, viel mejor como manche Ideen de "den Großen":
-------------------------------------------------------------------
Eigentlich stört mich en el oben erwähnten
GridLayout gl = (GridLayout) findViewById(R.id.GridLayout1);
sí una bastante otro Sache.
Als Yo así anfing, war mein Gedanke: Was Por favor, es el mikrige R como 
Muss bastante bedeutungslos oder gaaanz wichtig ser.
Hab's herausgefunden, eigentlich debería en lugar de des simplen R.id.GridLayout1 ordentlich
app.resources.layout.activity_main.GridLayout.android:id="@+id/GridLayout1"
más o menos ähnlich posición. Dann wäre el Programmzeile total auch imposanter y uno hätte mehr Ehrfurcht antes Android Java.
Sí, beim resources ha uno auch todavía gegeizt y sólo drei Buchstaben spendiert, pero la Unterpunkt drawable es sí dafür no para drw gekürzt! Man es en Ausgleich bemüht.
Über Syntax puede ser siempre fachsimpeln, el Thema es ergiebig como el Wetter. |
|
| |
| |
| |
|
(916)
Deutsch
English
Français
Español
Italia