XProfan

Jac
de
Lad

Mir ists egal, obs bleibt oder wegkommt. Von mir aus können die ganzen alten Befehle weg, das bringt sicher etwas Performance und weniger Speicherverbrauch der EXE und PRC. Oder der Compiler übersetzt das automatisch in die neuen Formen, das wäre am idealsten: abwärtskompatibel und doch flott. Ja, das wäre gut!

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

Da Wend exakt dem EndWhile entspricht, wird keine Exe kleiner durch weglassen. Lediglich Compiler und Interpreter ein paar Byte

Aber das weglassen der alten Funktionen wie @Add() @Sub usw. werden für kleinere Runtime und Exe sorgen

Jac
de
Lad

Irgendwas wird schon irgendwelche Vorteile bringen.

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

Hm ok also ich mag wend, endwhile ist nicht so schnell zu tippen und sieht zudem blöd aus. Ja es sieht blöd aus

Sollen Quelltexte blöd aussehen? Roland wird warscheinlich das wend - unabhängig zu dieser Umfrage abschaffen. Aber das ist doch garnicht schlimm! Ich schreibe einfach weiter wend, xpse wirds schon richten. Wenn xpse als Compiler angegeben ist braucht wend ja nicht gelb hinterlegt werden, ebenso die createbefehle. So!

Dietmar
Horn

Hallo,

eigentlich ist mir das auch egal, ob das Wend nun bleibt, oder nicht, denn mit Suchen-Ersetzen kann man seine Codes ja leicht anpassen.

Daß die Operatoren-Funktionen wegfallen sollen, das stört mich schon eher. Ich kann das wirklich bald nicht mehr nachvollziehen, warum es regelmäßig zu solchen und ähnlichen Ankündigungen kommen muß, die zu Inkompatibilitäten mit älteren Codes führen. Da könnte man ja glatt vermuten, daß es wirklich nur eine Hand voller XProfaner gibt, die ihre Programme über mehrere Jahre hinweg pflegen und weiterentwickeln. Sicherlich könnte man sich da dann wieder ein paar eigene Funktionen schreiben und mit Suchen-Ersetzen seine Codes anpassen. Doch einen richtigen Sinn kann ich daran nicht erkennen.

Da würde ich es schon für zukunftsträchtiger erachten, irgendwann ab XProfan 11 oder 12 oder 13 einen echten Schnitt zu machen und erbarmungslos sämtliche Altlasten zu entfernen, was meiner Meinung nach schon längst überfällig ist (und nicht in einem Jahr 5 oder 7 Befehle weg, und im nächsten Jahr dann wieder ein paar ältere Befehle, usw.). In der Summe würde das dann wahrscheinlich bestimmt zu einer spürbaren Geschwindigkeitssteigerung führen. Bei dieser Gelegenheit könnten dann auch die angestaubten vorgefertigten Dialoge und Icons aus Interpreter und Runtime endlich gekillt und / oder modernisiert, sowie die maximal mögliche Zeilenzahl weiter erhöht werden. Klar werden da jetzt gleich wieder einige mit dem Reshacker kommen und sagen, daß man sich damit seine Ressourcen ja selber anpassen kann. Doch wenn schon mal eine Generalüberholung in Angriff genommen wird, dann sollte das meines Erachtens nicht nur bei einer kleinen Durchsicht mit ein paar Verschleißreparaturen hängenbleiben. Ganz unter dem Motto: Lieber ein Ende mit Schrecken, als ein Schrecken ohne Ende!.

Falls zukünftig vielleicht auch noch ein neuer Compiler daherkommt, der nativen Code erzeugt, wäre die Sache wirklich rund. Und solche Sachen wie XPSE, XPIA und ROC sollten dann auch gleich fix und fertig in das neue XProfan eingebaut sein, genau wie z.B. sämtliche Funktionalitäten aus solchen DLLs, wie SK*.DLLs und noch ein paar mehr, sowie ausnahmslos allen iF- und A.-Miethe-Units, u.ä. - also alles das, was sich im Laufe der letzten Jahre als Standard für XProfan-Programmierer etabliert hat endlich mal unter eine Haube bringen.

Notfalls gibt es dann eben erstmals nicht in 1-Jahresabständen ein neues XProfan-Update, sondern erst nach 2 oder 3 Jahren, bis das alles eingetütet ist. Ob das dann beim Namen XProfan bleiben, oder die vollständig runderneuerte Version dann in XProfan-Professional, XXL-Profan oder sonstwie umbenannt wird, das wäre dann nebensächlich. Vielleicht könnte die Umstellung auf 64-Bit-XProfan ja ein würdiger Anlaß für eine solche Generalüberholung sein, ähnlich wie damals der Schnitt zwischen Profan² 4.5 und Profan² 5.0 (bzw. der Sprung von 16 Bit nach 32 Bit)?

Das Anpassen (oder völlige Neuschreiben) älterer Codes wäre dann eine einmalige Mühe, der sich wahrscheinlich jeder gerne unterziehen würde, wenn dadurch seine XPRF-Programme auf Geschwindigkeit getrimmt und (mit einfachen Standard-PRF-Befehlen) ein aktuelleres Outfit bekommen werden.

Ein angenehmer Nebeneffekt wäre dann sicherlich auch, daß nicht in jedem Jahr solche Diskussionen aufkommen und Heiko R. nicht regelmäßig zu seiner Gitarre greifen müßte, um neue Protest-Songs zu erschaffen (siehe GoTo-Song).

Mag sein, daß ich mich schon wieder etwas weit aus dem Fenster gelehnt habe, aber übt bitte vielleicht etwas Nachsicht mit solch einem alten und senilen Hörnchen wie mir ...

Gruß
Dietmar

@Nico: Kann es sein, daß Dein Hase eins auf die Nuß bekommen hat? Irgendwie hat das Vieh einen etwas geschwollenen Blick. Falls er irgendwann auch noch eins aufs andere Auge kriegt, dann sähe er eher aus wie eine Eule (oder wie iFs fettes Karnickel) ...

Multimedia für Jugendliche und junge Erwachsene - MMJ Hoyerswerda e.V. [...]

Windows 95 bis Windows 7
Profan² 6.6 bis XProfan X2 mit XPSE

Das große XProfan-Lehrbuch: [...]

RGH

Was das tatsächliche und engültige Wegfallen von Keywörtern betrifft, mal eine Klarstellung:

Bei den Keywörtern, die intern schon jetzt weggefallen sind und vom integrierten Precompiler in Interpreter und Compiler in die aktuelle Syntax übersetzt werden, besteht vorerst keine Gefahr. Das betrifft also im Wesentlichen die Createxxx- und dBxxx-Funktionen und auch WEND, aber auch SET-Befehle oder den Messagebox-Befehl, der durch die gleichnamige Funktion ersetzt wird. (In der Hilfe zu XProfan 10 werde ich die Liste der veralteten Keywords um ein Kennzeichen erweitern, aus dem hervorgeht, welche dieser Keywords vom internen Precompiler behandelt werden.) Hier besteht also so schnell klein Zwang, darauf zu verzichten. Den freundlichen gelben Hinweis kann man in diesen Fällen also ignorieren.

In der Hilfe werde ich die veralteten Keywords aber nicht mehr erwähnen, da es gerade für einen Neueinsteiger verwirrend ist, wenn es für ein und dieselbe Funktionalität auf mehrere Befehle und Funktionen gibt oder mehrere Formen der Syntax möglich sind.

Etwas anderes sind zum Beispiel, die Funktionen, die durch Operatoren ersetzt wurden. Die werden in XProfan 11 definitiv nicht mehr vorhanden sein und zu einer gewissen Verschlankung der Runtime führen.

Gruß
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

Nico
Madysa

Nochmals: Dass die Operatoren-Funktionen wegfallen, geht mir, ehrlich gesagt, am *piep* vorbei (Tschuldigung Dietmar).

@RGH: Du kannst doch das wend z.B. weiterhin in der Referenz zu while/whileloop erwähnen - sonst wissen fortgeschrittene Einsteiger am Ende garnicht, dass es so was überhaupt gibt!

@Dietmar: Meister Lampe ist aufm Weg zur Arbeit mal dem Isegrim begegnet...

Nico Madysa

28.09.2006 ▲

Frank
Abbing

[quote:a95660b9eb]@RGH: Du kannst doch das wend z.B. weiterhin in der Referenz zu while/whileloop erwähnen - sonst wissen fortgeschrittene Einsteiger am Ende garnicht, dass es so was überhaupt gibt![/quote:a95660b9eb]
Darum geht es ja, Nico. Es ist geplant, es irgendwann einmal ganz wegzumachen. Zuvor wird es aber schonmal gut versteckt, damit Neulinge gar nicht erst anfangen, es zu benutzen. Sodass am Ende nur noch wenige Quellcodes geändert werden müssen, wenn es ganz weggefallen ist. Ich halte das für eine vernünftige Praxis.

28.09.2006 ▲