| |
| |
|
 | 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... |
|
| |
| |
| |
|
|
E.T. | Yo glaub el Gedanke gefällt me  |
|
| |
| 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 | La idea find Yo muy schön. Ein pocos solcher Sachen son tan auch en XProfan ya angedeuted. Z.B. son el ganzen Move-Características todos bajo una Dach.
Was es entonces aber con Dopplern como:
Size(File "/...")
y
file size s
Sollen solche Sachen zweimal zugänglich ser oder más bien en eins beschränken. Also entweder de el Función (en el Sinne de Aktion) her oder vom Objeto. |
|
| |
| |
| |
|
|
| Exactamente,
dafür hätte Yo el Solución parat:
size y file son a) Konstanten y b) Características
So kann size file f erkannt voluntad así size(file,f) y aber auch file size f a file(size,f)
Hindernis: Der Espacio-Operator en:
size file f
él kann no wissen si size(file(f)) gemeint es oder size(file,f). |
|
| |
| |
| |
|
|
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: [...] |
|
| |
| |
| |
|
(456)
Deutsch
English
Français
Español
Italia