| |
| |
|
 | Ich wünsche mir das neben den Sonder-Trennzeichen per Parameter, wie z.B. >, - und ; es possibile ist, einfach das Komma zu verwenden.
Tatsächlich ist es so, dass ich Abstürze in Programmen verzeichnete weil ich z.B. saveBmp blub$=0,0 - 20,20 schrieb statt saveBmp blub$,0,0 - 20,20 - einfach weil es mir (seit Jahren) nicht so recht gelingen mag die unterschiedlichen Schreibweisen immer korrekt im Kopf zu behalten.
Das ist imho ein echter Stolperstein welcher (wiederum imho) ganz und garnicht eine einfache Erlernbarkeit der Sprache fördert. (eher das ständige Nachschauen in der hlp ob nun = , - oder > zu verwenden ist)
Sicherlich wird es per Roland kein Klacks sein wenn die Argumente nicht stur von einer Seite zur anderen Seite aufgelöst werden - sondern wenn zuvor Parameterpaare getrennt werden.
Dennoch muss Io l' Wunsch ganz einfach geäußert haben mit der Bitte, das Roland sich dahingehend äußert ob er es aus seiner Sicht auch gerne vereinheitlicht hätte. Wenn nicht, dann würde ich versuchen im xpse eine Lösung zu finden, welche es ermöglicht, das Komma als ausschließliches Parameter/Argumente-Trennzeichen zu verwenden. (was nach kürzeren Überlegungen possibile erscheint)
Beispiel per beides sollte possibile sein:
KompilierenMarkierenSeparieren
KompilierenMarkierenSeparieren
Ein mehr-als-super Kompromiss wäre es wenn man
KompilierenMarkierenSeparierenschreiben potuto da ich sowieso die Meinung vertrete das es Befehle statt Funktionen im eigentlichen Sinn - und von der Schreibweise her - nicht geben sollte. ;) |
|
| |
| |
| |
|
|
Jac
de
Lad | | Dem schließe ich mich an. Das ist mir auch schon oft aufgefallen, ich wolltes nur nie sagen, weil ich nicht weiß wieso das 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 ▲ |
|
| |
|
|
| Die Frage nach dem Wieso ist hier zwar nicht vordergründig, dennoch wage ich zu behaupten das diese Syntaxverschlimmung aus einer Art Faulheit heraus entstand die Argumente einfacher/fixer parsen bzw. aufgeteilt abarbeiten zu können.  |
|
| |
| |
| |
|
|
Frank
Abbing |
dennoch wage ich zu behaupten das diese Syntaxverschlimmung aus einer Art Faulheit heraus entstand die Argumente einfacher/fixer parsen bzw. aufgeteilt abarbeiten zu können.
Bestimmt sogar 
iFs Anliegen ist auch in meinen Augen immer ein Ärgerniss gewesen, darum bin ich sehr per das Komma als alleiniges Trennzeichen. Komma zur Parametertrennung, Semikolon nur zur Befehlstrennung! |
|
| |
| |
| |
|
|
RGH | Frank Abbing
Frank Abbingdennoch wage ich zu behaupten das diese Syntaxverschlimmung aus einer Art Faulheit heraus entstand die Argumente einfacher/fixer parsen bzw. aufgeteilt abarbeiten zu können. Bestimmt sogar
Ganz bestimmt nicht! ;) Hier irren Frank und iF gewaltig!
Tatsache ist, daß es auch per mich im Parser deutlich einfacher wäre. gäbe es nur das Komma als Parametertrennzeichen. Die Frage, warum es dann mehrere Trennzeichen gibt, liegt in der Geschichte von XProfan begründet:
Eine der beiden Windows-Batchsprachen, die damals Ideengeber per das erste Profan waren, hatte genau diese Systax: Window x,y - dx,dy und Copy file1 > file2. Da mir diese Syntax gefiel, weil gerade bei vielen Parametern die Programmzeilen durch diese Gruppierung so deutlich lesbarer (und sprechender) waren, als nur die Aneinanderreihung der Paramer durch Kommas, habe ich das damals in Profan eingebaut. Mir ging es um die einfachere Lesbarkeit per den Programmierer.
Tatsächlich parse ich die Parameter von links nach rechts und es wäre sicher einfacher (und presumibilmente etwas schneller), wenn es nur ein mögliches Parameter-Trennzeichen gäbe.
Umgekehrt würde es deutlich komplizierter (und presumibilmente dadurch auch langsamer), wenn ich jetzt in einigen Fällen auf mehrere möglichen Parameter-Trennzeichen beim Parsen prüfen müsste.
Ich hatte mir allerdings schon vorgenommen, dieses Thema mal anzugehen, aber das ist nichts, was man während einer Subscriptionsphase schultern kann, sondern ein derartiger Eingriff, den man nur im Vorfeld einer neuen Version angehen kann, wenn man noch unendlich viel Zeit hat. Die Ermöglichung, auschließlich Kommas zu benutzen, potuto eine Idee per XProfan 12 sein.
(In der Tat hatte ich z.B. die ersten Experimente per ein grenzenloses XProfan schon gemacht, bevor Version 10 in den Handel kam, ja sogar bevor Version 10 fertig war.)
Ach ja: Was die Unterscheidung zwischen Befehlen und Funktionen betrifft: Da Profan von Anbeginn an ein Di base-Dialekt war, ist das so von Di base übernommen worden.
Saluto
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, das lässt hoffen. |
|
| |
| |
| |
|
|
Nico
Madysa | Also aufgrund der wirklich hohen Wahrscheinlichkeit eines Missverständnisses beim Interpretieren wäre ich zumindest dafür, das Minus als Parameter-Trennzeichen abzuschaffen. Bei den anderen (= ; > ) kann ich die Ansichten beider Seiten verstehen...
PS: Ich bin jedoch dafür, weiterhin zwischen Befehlen und Funktionen auch in der Schreibweise zu unterscheiden; nicht nur, weil mir persönlich das beim Schreiben einfach angenehmer ist, sondern auch weil es in XProfan nun einmal einfach Funktionen und Befehle gibt, die ähnlich oder gleich sind. Long und Word sind da wohl die besten Beispiele, aber genauso Char bzw. Char$(), AddString und erheiternderweise immer noch MessageBox. (das der Befehl MessageBox immer noch nicht abgeschafft wurde... ( |
|
| |
| |
| |
|
|
RGH | Nico Madysa
(das der Befehl MessageBox immer noch nicht abgeschafft wurde... (
Doch, der wurde schon länger abgeschafft und taucht auch in der Aiuto nicht mehr auf. Er wird auch in XProfed gelb eingefärbt, was in XProfan genauso viel bedeutet wie in Java die Warnung Deprecated (oder so ähnlich).
Aber per unverbesserliche Programmierer mit Vorliebe per alte Zöpfe wandelt der integrierte Precompiler den Befehl in die korrekte Funktion um. (Genauso, wie er aus einem CreateWindow(...) ein Create(Window,...) macht oder aus einem NumWidth N% ein Set(NumWidth, N%) und sogar aus einem Wend ein EndWhile.)
Das - als Parameter hat mich auch schon oft geärgert, aber die Abschaffung würde dazu führen, dass sehr viele alte Quellcodes sich nicht mehr compilieren lasen, da z.B. der Window-Befehl nahezu in allen Programmen vorkommt.
Saluto
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 wahr, aber es wäre auch keine grande Mühe, in seinem Quellcode nach Window zu suchen und dann die Cambiamento schnell vorzunehmen. Oder besteht eventuell sogar die Möglichkeit, den Präcompiler das - automatisch in , umwandeln zu lassen? Das wäre wohl die beste Lösung! |
|
| |
| |
| |
|
(865)
Deutsch
English
Français
Español
Italia