| |
| |
|
 | 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... |
|
| |
| |
| |
|
|
E.T. | je glaub qui idée comme 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 | L'idée find je très joli. un paire solcher Sachen sommes oui aussi dans XProfan déjà angedeuted. Z.B. sommes qui ganzen Move-Funktionen alle sous einem toit.
quoi ist ensuite mais avec Dopplern comment:
Size(File "/...")
et
file size s
devoir solche Sachen zweimal zugänglich son ou bien lieber sur une beschränken. alors entweder de qui Funktion (im Sinne de Aktion) her ou bien vom objet. |
|
| |
| |
| |
|
|
| oui c'est ca,
pour hätte je qui Solution prêt:
size et file sommes a) Konstanten et b) Funktionen
So peux size file f erkannt volonté so size(file,f) et mais aussi file size f trop file(size,f)
Hindernis: qui Space-Operator chez:
size file f
il peut pas savons si size(file(f)) gemeint ist ou bien size(file,f). |
|
| |
| |
| |
|
|
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: [...] |
|
| |
| |
| |
|
(516)
Deutsch
English
Français
Español
Italia