| |
| |
|
 | je wünsche mir cela près de den Sonder-Trennzeichen pour paramètre, comment z.B. >, - et ; es possible ist, simple cela Komma trop verwenden.
réellement ist es so, dass je Abstürze dans Programmen verzeichnete weil je z.B. saveBmp blub$=0,0 - 20,20 schrieb statt saveBmp blub$,0,0 - 20,20 - simple weil es mir (depuis Jahren) pas so droite gelingen mag qui unterschiedlichen Schreibweisen toujours korrekt im tête trop behalten.
c'est imho un echter Stolperstein quel (wiederum imho) entier et garnicht une simple Erlernbarkeit qui Discours fördert. (plutôt cela ständige Nachschauen dans qui hlp si eh bien = , - ou bien > trop verwenden ist)
Sicherlich wird es pour Roland ne...aucune Klacks son si le Argumente pas stur de einer page zur anderen page aufgelöst volonté - mais si zuvor Parameterpaare getrennt volonté.
toutefois muss Je l' Wunsch entier simple geäußert avons avec qui s'il te plaît, cela Roland sich dahingehend äußert si il es aus seiner Sicht aussi volontiers vereinheitlicht hätte. si pas, ensuite serait je versuchen im xpse une Solution pour trouver, quelle es permet, cela Komma comme ausschließliches paramètre/Argumente-Trennzeichen trop verwenden. (quoi pour kürzeren Überlegungen possible erscheint)
Beispiel pour beides sollte possible son:
KompilierenMarqueSéparation
KompilierenMarqueSéparation
un plus-comme-super Kompromiss wäre es si on
KompilierenMarqueSéparationécrivons pourrait là je sowieso qui attitude vertrete cela es Befehle statt Funktionen im réel Sinn - et de qui Schreibweise her - pas donner sollte. ;) |
|
| |
| |
| |
|
|
Jac
de
Lad | | Dem schließe je mich à. c'est mir aussi déjà souvent aufgefallen, je wolltes seulement nie dire, weil je pas sais wieso cela so ist. |
|
| |
| Profan² 2.6 bis XProfan 11.1+XPSE+XPIA+XPRR (und irgendwann XIDE)
Core2Duo E8500/T2250, 8192/1024 MB, Radeon HD4850/Radeon XPress 1250, Vista64/XP | 13.02.2008 ▲ |
|
| |
|
|
| qui Frage pour dem Pourquoi ist ici zwar pas vordergründig, toutefois wage je trop behaupten cela cet Syntaxverschlimmung aus einer Art paresse heraus entstand qui Argumente einfacher/fixer parsen bzw. aufgeteilt abarbeiten trop peut.  |
|
| |
| |
| |
|
|
Frank
Abbing |
toutefois wage je trop behaupten cela cet Syntaxverschlimmung aus einer Art paresse heraus entstand qui Argumente einfacher/fixer parsen bzw. aufgeteilt abarbeiten trop peut.
Bestimmt sogar 
iFs Anliegen ist aussi dans meinen Augen toujours un Ärgerniss gewesen, tout autor suis je très pour cela Komma comme alleiniges Trennzeichen. Komma zur Parametertrennung, Semikolon seulement zur Befehlstrennung! |
|
| |
| |
| |
|
|
RGH | Frank Abbing
Frank Abbingtoutefois wage je trop behaupten cela cet Syntaxverschlimmung aus einer Art paresse heraus entstand qui Argumente einfacher/fixer parsen bzw. aufgeteilt abarbeiten trop peut. Bestimmt sogar
entier bestimmt pas! ;) ici irren Frank et iF gewaltig!
Tatsache ist, qui es aussi pour mich im Parser deutlich einfacher wäre. gäbe es seulement cela Komma comme Parametertrennzeichen. qui Frage, pourquoi es ensuite plusieurs Trennzeichen gibt, liegt dans qui Geschichte de XProfan begründet:
une qui beiden Windows-Batchsprachen, qui autrefois Ideengeber pour cela erste Profan étions, hatte oui c'est ca cet Systax: Fenêtre x,y - dx,dy et Copy file1 > file2. là mir cet Syntax gefiel, weil justement chez vielen Parametern qui Programmzeilen par cet Gruppierung so deutlich lesbarer (et sprechender) étions, comme seulement qui Aneinanderreihung qui Paramer par Kommas, habe je cela autrefois dans Profan incorporé. Mir ging es à einfachere Lesbarkeit pour den Programmierer.
réellement parse je qui paramètre de à gauche à droite et es wäre sûrement einfacher (et probablement quelque chose plus rapide), si es seulement un mögliches paramètre-Trennzeichen gäbe.
renversé serait es deutlich komplizierter (et probablement dadurch aussi langsamer), si je maintenant dans einigen Fällen sur plusieurs möglichen paramètre-Trennzeichen beim Parsen vérifier devrait.
je hatte mir allerdings déjà vorgenommen, cet Thema la fois anzugehen, mais c'est rien, quoi on au cours de einer Subscriptionsphase schultern peux, mais un derartiger intervention, den on seulement im Vorfeld einer neuen Version angehen peux, si on encore unendlich viel Zeit hat. qui Ermöglichung, auschließlich Kommas trop benutzen, pourrait une concept pour XProfan 12 son.
(dans qui acte J'ai eu z.B. qui ersten Experimente pour un grenzenloses XProfan déjà gemacht, bevor Version 10 dans den négoce kam, oui sogar bevor Version 10 fertig était.)
ah oui: quoi qui Unterscheidung entre Befehlen et Funktionen betrifft: là Profan de Anbeginn moins un BASIC-Dialekt était, ist cela so de BASIC übernommen worden.
Salut
Roland |
|
| |
| Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4 | 13.02.2008 ▲ |
|
| |
|
|
| | Super, cela peut espérer. |
|
| |
| |
| |
|
|
Nico
Madysa | alors aufgrund qui wirklich hohen probabilité eines Missverständnisses beim Interpretieren wäre je zumindest pour, cela Minus comme paramètre-Trennzeichen abzuschaffen. chez den anderen (= ; > ) peux je qui Ansichten beider Seiten comprendre...
PS: je suis cependant pour, weiterhin entre Befehlen et Funktionen aussi dans qui Schreibweise trop unterscheiden; pas seulement, weil mir personnelle cela beim écrivons simple angenehmer ist, mais aussi weil es dans XProfan eh bien einmal simple Funktionen et Befehle gibt, qui ähnlich ou bien juste sommes. Long et Word sommes là wohl qui besten Beispiele, mais genauso Char bzw. Char$(), AddStrings et erheiternderweise toujours MessageBox. (cela qui Befehl MessageBox toujours pas abgeschafft wurde... ( |
|
| |
| |
| |
|
|
RGH | Nico Madysa
(cela qui Befehl MessageBox toujours pas abgeschafft wurde... (
Doch, qui wurde déjà länger abgeschafft et taucht aussi dans qui Aider pas plus sur. il wird aussi dans XProfed jaune eingefärbt, quoi dans XProfan genauso viel bedeutet comment dans Java qui avertissement Deprecated (ou bien so ähnlich).
mais pour unverbesserliche Programmierer avec Vorliebe pour vieille Zöpfe wandelt qui integrierte Precompiler den Befehl dans qui korrekte Funktion um. (Genauso, comment il aus einem CreateWindow(...) un Créer(Fenêtre,...) pouvoir ou bien aus einem NumWidth N% un Set(NumWidth, N%) et sogar aus einem Wend un Endwhile.)
cela - comme paramètre hat mich aussi déjà souvent geärgert, mais qui abolition serait en supplément mener, dass très viele vieille Quellcodes sich pas plus compilieren lasen, là z.B. qui Fenêtre-Befehl nahezu dans allen Programmen vorkommt.
Salut
Roland
. |
|
| |
| Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4 | 15.02.2008 ▲ |
|
| |
|
|
Nico
Madysa | | Wohl véritable, mais es wäre aussi aucun grand Mühe, dans seinem Quellcode pour Fenêtre trop chercher et ensuite qui Changement vite vorzunehmen. ou bien besteht eventuell sogar qui Possibilité, den Präcompiler cela - automatisch dans , transformer trop laisser? cela wäre wohl qui beste Solution! |
|
| |
| |
| |
|
(1.356)
Deutsch
English
Français
Español
Italia