Zitat von
mkinzler:
Es wäre
imho sinnvoll den Compiler von der Plattform zu trennen. Damit meine ich das es nicht einen Delphicompiler für
Win32, einen für .Net, einen C++-Compiler für
Win32 und einen für .Net sondern einen für Delphi und einen für C++. Im 2. Schritt würde dann der eigentliche Code für die Plattform (
Win32, .Net, Mono, Linux, MacOS) erzeugt werden.
Ja das wär schon was, aber in der Realität wahrscheinlich sehr komplex (bislang haben sie sich ja sogar gegen ein Two-Pass Compiler gesträubt, da will man ja sowas gar nicht erst ansprechen
Den Compiler zu opensourcen wär aber ein schöner Schachzug...
Zitat von
mkinzler:
Das würde zur mangelnden Rückwärtskompatibilität führen.
Nun ja. Schau doch mal unter .Net 2.0 den Namespace System.Collections an. Der ist bereits suboptimal, weil .Net 1.0/1.1 keine Generics kannten. D.h. bereits in Version 2 (!) fängt das Chaos an (sonst würde es keine ArrayList Klasse geben). Delphi ist nun das selbe, nur multipliziert mit 20 oder sowas, wenn man die Pascals für Dos mitzählt.
Aber es gibt doch Wege: Man führt eine neue Syntax ein und erlaubt dann beide Varianten, mit deprecated Warnings beim Compilieren der alten. Abwärtskompatibilität ist ja schön und gut, aber man muss doch auch mal bestimmte Dinge loslassen können.
Bei Delphi wird immer auf so uralt Versionen Rücksicht genommen. Das liegt doch aber nur daran, dass 1) neue Versionen zu verbuggt erscheinen oder 2) neue Versionen zu teuer sind. Und beidem kann man doch Herr werden. Wäre ein neues Delphi eine echte Alternative, so würden die Leute mitgenommen werden - man könnte die Sourcen schrittweise modernisieren und die Leute müssten keine 6 Versionen überspringen.