[Chrome] Der Blick über den Tellerrand

[Christian S.]

Der Blick über den Tellerrand

In den letzten Tagen habe ich mich eingehend mit einem Produkt beschäftigt, welches meines Erachtens viel zu wenig Beachtung erhalten hat. Die Rede ist von RemObjects Chrome. Chrome ist ein Pascalcompiler, welcher sich in das Visual Studio integriert und sowohl .NET 1.1 als auch .NET 2.0 vollständig unterstützt. Außerdem bietet Chrome eine Vielzahl von Sprachfeatures, die es klar von anderen Pascaldialekten wie Delphi oder Free Pascal unterscheiden.



Meine Highlights
Ich möchte an dieser Stelle keine komplette Liste abarbeiten, das darf jeder auf der Seite des Herstellers selber tun. In diesem Artikel werde ich eine ganz subjektive Auswahl treffen. Da ich noch nicht allzu lange mit Chrome arbeite, werden das wahrscheinlich noch nicht einmal die wirklichen "Highlights" der Sprache sein.

Als Erstes möchte ich auf Dinge eingehen, die der Compiler für den Programmierer erledigt. Und davon gibt es einige. Vor allem anderen gefällt mir dabei die so genannte "Type Inference", was soviel heißt, dass der Compiler nicht nur die Typen meiner Variablen erkennt, sondern erkennt, dass ich überhaupt eine neue Variable einführen will. Letzteres gilt für Variablen mit begrenzter Lebensdauer (also z.B. in with-Anweisungen).

Wie sieht das genau aus? So z.B.:

Delphi-Quellcode:

with foo := new Tfoo() do
begin
  foo.DoSomething();
end;

Wir müssen foo nirgendwo deklarieren und wir müssen auch nicht den Typ von foo angeben.

Ähnlich einfach kann man bei Bedarf neue Variablen einführen.

Delphi-Quellcode:

begin
  var bar := new TBar();
end;

Diese Zeile steht, wie man sieht, irgendwo im Quelltext und nicht im Deklarationsteil.

Ähnlich praktisch ist auch die Deklaration von Zählern:

Delphi-Quellcode:

for i : Integer := 0 to 5 do

In der for-schleife muss man diese Syntax wählen, welche auch eine Variablendeklaration enthält. Sie ist mit den oben demonstrierten Syntaxschemas kompatibel. Type Inference ist das dann natürlich nicht mehr. ;-)

Ein guter Punkt, um zum nächsten Beispiel zu kommen, wo der Compiler Arbeit übernimmt. Oft kommt es vor, dass eine Property einfach nur ein privates Feld kapselt, also gar keine get- und set-Methoden vorhanden sind.

Hier hilft Chrome, den ewig gleichen Standardcode zu vermeiden, indem es folgende Syntax erlaubt:

Delphi-Quellcode:

type
  TFoo = public class
  public
    property aProp : String;
  end;

Mehr ist nicht nötig, um eine Property anzulegen, der Rest wird implizit deklariert. (Obiges Beispiel zeigt ein weiteres Chrome-Feature: Typensichtbarkeit wird vollständig unterstützt.)

Kommen wir zu Kleinigkeiten, bei denen man erst einmal denkt, dass das nicht erwähnenswert ist. Aber zumindest mir geht es so, dass die Kleinigkeiten, denen man immer wieder begegnet, einen hohen Stellenwert erhalten. Da wäre zum einen die exit-Methode, der man einen Parameter übergeben kann. Anstatt also

Delphi-Quellcode:

if aVal = anotherVal then
begin
  result := someVal;
  exit;
end;

schreiben zu müssen, reicht ein

Delphi-Quellcode:

if aVal = anotherVal then exit(someVal);

. Wie gesagt, eine Kleinigkeit, aber man gewöhnt sich dran ;-)

Nächste Kleinigkeit: "empty". Schonmal eine Methode gehabt, die im interface stehen musste, aber nur ein Dummy war? Kein Problem. Einfach folgendermaßen deklarieren:

Delphi-Quellcode:

type
  TFoo = public class
  public
    method aMethod; empty;
  end;

Im implementation-Teil muss kein Dummy mehr angelegt werden. Kleinigkeiten, an die man sich gewöhnt ...



Auffällige Sprachunterschiede zu Delphi
Ich könnte meine Highlights noch fortsetzen und je länger ich mit Chrome arbeite, werde ich Neue entdecken. Aber das würde wohl mit der Zeit langweilig werden. Daher will ich noch ein paar auffällige Sprachunterschiede vorstellen, die ich nicht so liebgewonnen habe, die aber trotzdem von Bedeutung sind.

Allen voran wäre da die Unterstützung von Generics. Sie sind eine der Voraussetzungen, die eine Sprache für .NET 2.0 erfüllen muss, und sie haben daher auch Einzug in Chrome gefunden. Die Syntax ist praktisch dieselbe wie in C#:

Delphi-Quellcode:

var li : List<Integer> := new List<Integer>();

oder auch (Zitat aus der Chrome-Doku)

Delphi-Quellcode:

type
  MyArrayList<T> = public class(ArrayList, IPersistentCollection)
    where T is PersistentObject, T has constructor;

Also auch die Unterstützung für Constraints ist da.

Weil ich an dieser Stelle nicht weiter auf Generics eingehen möchte (das ginge zu weit), möchte ich Euer Augenmerk auf das erste Code-Beispiel zu Generics lenken und zwar auf die Konstruktor-Syntax. Da .NET keine Konstruktoren mit Namen kennt, wurde auch in Chrome darauf verzichtet. Anstatt einen Defaultnamen wie z.B. "Create" und die Funktionensyntax zu verwenden, wurde auf die von C# bekannte new-Syntax zurückgegriffen. Es ist Geschmackssache, was man besser findet, logisch erscheinen mir beide. Ich muss aber zugeben, dass es am Anfang komisch aussieht, in Pascal mit "new" zu arbeiten ;-)

Ein weiterer Sprachunterschied zu Delphi sind die so genannten "Class Contracts". Class Contracts dienen der Überprüfung von Bedingungen, die vor / nach der Ausführung einer Methode wahr sein müssen (require / ensure) bzw. innerhalb einer Klasse immer erfüllt sein müssen (Invariants).
An dieser Stelle sei erneut ein Beispiel aus der Chrome-Doku zitiert:

Delphi-Quellcode:

method MyObject.DivideBy(aValue: Integer);
require
  aValue <> 0;
begin
  MyValue := MyValue/aValue;
end;

Es spricht eigentlich für sich, was hier passiert. Es wird sichergestellt, dass aValue nicht Null ist, weil durch Null zu teilen im Allgemeinen keine gute Idee ist. Invariants möchte ich an folgendem Beispiel demonstrieren:

Delphi-Quellcode:

type
  TComplex = public class
  public
    property length : Double;
  public invariants
    length >= 0;
  end;

Hier wird festgelegt, dass die Eigenschaft "length" niemals kleiner Null sein darf. Wird sie es doch, wird eine Ausnahme geworfen. (Übrigens wäre diese Klasse so fertig, im implementation-Teil muss nichts mehr gemacht werden.)

Dass auf jeden Topf ein Deckel passt, ist bekannt. In Delphi muss man die Deckel allerdings selber aussortieren, was in Chrome für einen erledigt wird. Ein Beispiel (wieder aus der Doku) macht es deutlich:

Delphi-Quellcode:

   
   x := new ArrayList();
   x.add('Test');
   x.add(123);
  for each matching S: String in x do
     console.writeline(s);

Anstatt, dass die foreach-Schleife stupide alle Elemente durchläuft und man selber dafür verantwortlich ist zu schauen, ob es sich um den richtigen Typen handelt, werden hier nur bei den Elementen in den Schleifenrumpf gesprungen, welche der matching-Bedingung entsprechen.

Den letzten hier genannten Sprachunterschied möchte einfach mal unkommentiert stehen lassen ;-)

Delphi-Quellcode:

  case forum of
    'df': DoDelphiForum;
    'csf': DoCSharpForum;
    'dl': DoDelphiLibrary;
    'csl': DoCSharpLibrary;
    else DoEntwicklerEcke;
  end;

Nobody is perfect
Doch auch Chrome hat Schwächen. Die liegen ganz klar nicht in der Sprache, sondern im Editor. Da ich momentan mit einem RC arbeite, will ich auf Fehler hier nicht eingehen, die können in der Final schon behoben sein. Es geht mir viel mehr darum, dass viele Refactoring-Funktionen entweder vollständig fehlen oder ungenügend umgesetzt wurden.

Smart Editing nennt sich das, was Chrome an Refactoring liefert. Doch was ist das? Zuerst einmal wären da die Navigation zwischen implementation- und interface-Abschnitt, wie man sie aus Delphi kennt. Ebenso die Klassenvervollständigung. Code Folding ist ebenfalls nichts Neues und das man Parameterlisten in einem Hint erhält, wenn man eine Funktion aufrufen will, ist inzwischen einfach Standard.

Die Code-Vervollständigung hat in Chrome einige wünschenswerte und praktische Ergänzungen erfahren. So wird das Erstellen von Properties dadurch unterstützt, dass man automatisch die entsprechenden get- und set-Methoden oder private Felder anlegen kann. Auch bietet die Vervollständigung beim Anlegen von Klassenoperatoren eine Liste der verfügbaren Operatoren. Eine Kleinigkeit, an die man sich wieder schnell gewöhnt: Tippt man "begin" und die Eingabetaste, wird das "end;" ergänzt und der Cursor an die richtige Stelle gesetzt.

Ein guter Ansatz, aber absolut nicht zu Ende gedacht, ist das Sync Rename. Damit sollte es eigentlich möglich sein, Mehtoden oder Klassen einfach umzubenennen. Leider heisst "Sync" hierbei nur, dass Änderung an diesen beiden Dingen (also Methode- und Klassennamen, anderes wird nicht unterstütz) synchron in interface- und implementation-Abschnitt gemacht wird. Aber im implementation-Abschnitt auch nur im Kopf der Methoden, nicht im Code. Und da muss ich einfach mal Fragen: Was soll das? Ich habe die Methode zigmal im Quelltext stehen und der ersetzt mir automatisch das Vorkommen, was ich am einfachsten selber finden kann? Na, vielen Dank auch.

Dann wäre da noch die automatische Deklaration von Variablen. Setzt man den Cursor auf einen Bezeichner und drückt eine Tastenkombination, erstellt Chorme eine entsprechende Property (Bezeicher fängt mir großen Buchstaben an), ein privates Feld (Bezeichner fängt mit "f" an) und ansonsten eine lokale Variable. Eine andere Tastenkombination erstellt eine neue Methode

Mehr an Refactoring gibt es nicht und das muss man einfach mal als mager bezeichnen. Da ist man deutlich mehr gewohnt und eine Firma, die ganz klar eine Konkurrenz zu Delphi präsentieren will, sollte auch auf diesem Bereich etwas mehr zu bieten haben. Und da muss man klar sagen: Delphi 2005 (2006 hab ich nicht) bietet deutlich mehr Komfort in diesem Bereich.


Mein Fazit
Ich habe den Kauf von Chrome nicht bereut und arbeite sehr gerne damit. Die Sprache bietet so viele Features, dass das Arbeiten trotz des dürftigen Editors Spaß macht. Ich entdecke immer wieder neue Features, die mir ein "Cool!" entlocken. Kurz um: Bei Chrome hat man einfach mal den Staub von der Sprache Pascal gewischt und das ist auch gut so. Das fehlende Refactoring ist ein deutlicher Mangel, aber es hat mich bisher nicht soweit gestört, dass es in mir Zweifel am Kauf von Chrome geweckt hätte.

Dieser Artikel kann auch auf meiner Homepage abgerufen werden: http://www.christian-stelzmann.de/artikel/chrome.htm
Crossposting Entwickler-Ecke: http://www.delphi-forum.de/viewtopic.php?t=60346



//edit: Link zur Chrome-Homepage eingefügt

[SirThornberry]

die genannten Features sind schon incht schlecht. Aber Irgendwie erinnert mich das ganze doch sehr stark an C/C++.
Delphi ist ja eigentlich so einfach für Einsteiger weil es feste richtlinien gibt wo Variablen declariert werden müssen und wo es nicht erlaubt ist. Bei dem von dir vorgestellten sind wir ja aber eigentlich wieder bei C/C++ was viel mehr kann aber für Anfänger doch vewirrender ist.

[Christian S.]

Hallo!

Ja, einige der Features von Chrome sind eine klare Abkehr von den Regeln, die Pascal dem Programmierer auferlegt, um sauberen Code zu erzwingen. Ich würde daher Delphi auch Chrome als Sprache für Anfänger vorziehen. Aber irgendwann ist man aus dem Stadium heraus, dass man einen Compiler braucht, der einem Vorschriften macht, um lesbaren Code zu erzeugen. Und an dem Punkt kommt mir Chrome sehr entgegen, weil es mir mehr Freiheiten gibt.

Grüße
Christian

[SirThornberry]

da stimme ich dir zu. Das erste was ich mich alledings gefragt habe war, was einen dazu bewegt zu Chrome zu wechseln statt gleich zu C/C++

[mkinzler]

Zitat:

Das erste was ich mich alledings gefragt hat was einen dazu bewegt zu Chrome zu wechseln statt gleich zu C/C++

Eher zu c#, da Chrome ja eine .Net-Sprache ist.

[DP-Maintenance]

Dieses Thema wurde von "Daniel" von "Klatsch und Tratsch" nach "Tutorials und Kurse" verschoben.

[Khabarakh]

Zitat:

Zitat von SirThornberry

die genannten Features sind schon incht schlecht. Aber Irgendwie erinnert mich das ganze doch sehr stark an C/C++.
Delphi ist ja eigentlich so einfach für Einsteiger weil es feste richtlinien gibt wo Variablen declariert werden müssen und wo es nicht erlaubt ist. Bei dem von dir vorgestellten sind wir ja aber eigentlich wieder bei C/C++ was viel mehr kann aber für Anfänger doch vewirrender ist.

Es ist ja nicht so, dass die Variablendeklaration nun verboten sei ;) . Chrome lässt dem Programmierer Einiges an Freiheit, wie man diese nutzt, muss jeder selbst entscheiden.

Sehr schöner Artikel, aber was hat dieses "T" in den Klassennamen verloren :stupid: ?

Btw: Hier gibt es eine Aufzählung der vielen restlichen Features. Mein Liebling ist 0 <= x < Count :love: .

[add]

Zitat:

Zitat von SirThornberry

da stimme ich dir zu. Das erste was ich mich alledings gefragt habe war, was einen dazu bewegt zu Chrome zu wechseln statt gleich zu C/C++

Nur weil man zu faul für explizite Variablendeklarationen ist, muss man noch lange nicht das gesamte Pascal-Konzept schlecht finden.
Why .NET? Why Chrome?

[Christian S.]

Hallo!

Richtig, C# ist eine starke Konkurrenz zu Chrome. Ich kann auch nicht ausschließen, dass ich beides parallel benutzen werde. Aber Chrome bietet auch gegenüber C# einige Vorteile. Da wären zum einen Array-Properties, die einen Namen haben (bei C# kann man ja leider nur this[foo] machen), Sets, Klassenreferenzen und (ich gebe es zu, ich bin Gewohnheitstier) eine vertraute Pascal-Syntax.

Aber ich will hier auch nicht behaupten, Chrome wäre das non-plus-ultra, das jetzt jeder benutzen soll. Chrome ist auch "nur" eine Programmiersprache und da gewichtet jeder die Eigenschaften, die eine Sprache hat oder nicht hat, anders. Ich wollte lediglich einen kleinen Einblick geben, damit sich dann jeder selber ein Bild machen und seine persönliche Berwertung erstellen kann.

Grüße
Christian

//Edit: "T" im Namen: Macht der Gewohnheit und ich wollte die Delphianer hier nicht zu sehr schocken :mrgreen:

[Daniel G]

*räusper*

Jetzt wär' noch nen Link auf die Seite ganz hübsch.... :stupid:

[mkinzler]

www.chromesville.com

[Alexander]

Ich finde es eigentlich auch recht gut, dass z.B. Variablen fest im Methodenkopf deklariert werden müssen. Ist einfach übersichtlicher. Gut, bei Variablen, die nur für eine For-Schleife benötigt werden, ist das vielleicht gar nicht so schlecht.
Aber nett, vielleicht kaufe ich mir das auch mal :)

Ein wenig Bedenken habe ich jedoch dabei, dass die Firma ja noch recht jung ist und evtl. schnell wieder vom Markt verschwinden kann. Oder Nachfolgeversionen nicht mehr abwärtskompatibel sind. Wer übersetzt mir dann mein eigentlich fertiges Programm in eine neue Sprache ?

Nachtrag:
Was ich aber sehr fair finde ist das:

Zitat:

Chrome 1.5 is a free update for all existing users of Chrome 1.0.

Eine deutsche Version fände ich auch nicht schlecht :)

[MagicAndre1981]

Zitat:

Zitat von Alexander

Wer übersetzt mir dann mein eigentlich fertiges Programm in eine neue Sprache ?

Lutz Roeders Reflactor :zwinker:

[MrSpock]

Hallo Christian,

Zitat:

Zitat von Christian S.

...
Ja, einige der Features von Chrome sind eine klare Abkehr von den Regeln, die Pascal dem Programmierer auferlegt, um sauberen Code zu erzwingen. Ich würde daher Delphi auch Chrome als Sprache für Anfänger vorziehen. Aber irgendwann ist man aus dem Stadium heraus, dass man einen Compiler braucht, der einem Vorschriften macht, um lesbaren Code zu erzeugen. Und an dem Punkt kommt mir Chrome sehr entgegen, weil es mir mehr Freiheiten gibt....

Hört sich an, wie irgendwann bin ich so gut, dass ich keinen sauberen Code mehr schreiben muss. Die Einschränkungen, die Pascal einem auferlegt, dienen nun mal auch dazu wartbaren Code zu schreiben und Fehler schon frühzeitig mit Hilfe des Compilers zu vermeiden. Ich programmiere jetzt schon seit über 20 Jahre und habe mich durch Pascal / Delphi nie eingeschränkt gefühlt, glaube aber gut wartbaren Code zu schreiben.Sinnvolle Erweiterungen hat es ja im Laufe der Zeit auch in Delphi's Pascal gegeben.

[Elvis]

Zitat:

Zitat von Alexander

Ich finde es eigentlich auch recht gut, dass z.B. Variablen fest im Methodenkopf deklariert werden müssen. Ist einfach übersichtlicher.

Das hört man von Chome newbies immer wieder. Dauert nicht lange und man sieht nur noch dann eine var section in ihren Codes, wenn sie sinnvoll oder notwendig ist.
Zum Bleistift wenn man die Variable auch in der "require" oder "ensure" Clause benutzen will.

Delphi-Quellcode:

var
  mieps := iif(assigned(someParameter),
               someParameter.GetMieps(),
               nil);
require
  assigned(someParameter);
  assigned(mieps);
  mieps.Count > 0;
begin
...
ensure
  mieps.Count = old mieps.Count - 1;
end;

Ansonsten benutzt man eher using oder with-Blöcke, da kann man sofort sehen wo der Wert herkommt und die Variable lebt nur in diesem Block.

Delphi-Quellcode:

using dialog := new MyDialogForm(SomeProperty := 'miep') do
begin
  if dialog.ShowDialog() = DialogResult.Ok then
    blabla
end;

Variablen am Beginn einer Methode bringen IMO keineswegs mehr Übersichtlichkeit. Wenn ich hingegen den Methodenrumpf zusammenklappe und erst auf die Contracts schaue weiß ich viel mehr über das was in der Methode passiert und vor allem welche Zustände sie benötigt und welchen Endzustand sie garantiert.

Zitat:

Ein wenig Bedenken habe ich jedoch dabei, dass die Firma ja noch recht jung ist und evtl. schnell wieder vom Markt verschwinden kann.

Chrome ist nur ein kleines Produkt von RO, ihren Hauptumsatz machen sie anscheinend mit Delphikomponenten wie dem RO SDK, Data abstract und Hydra.
btw: hinter Klaradingsens Link findest du auch warum es Chrome überhaupt gibt. RO hat nämlich seine .Net Versionen der Delphiprodukte in Chrome geschrieben. Solange es also das RO SDK un DA gibt, wird es zwangsläufig auch Chrome geben. ;)

Zitat:

Oder Nachfolgeversionen nicht mehr abwärtskompatibel sind.

Sie haben selbst legacy switches eingebaut um halbwegs kompatibel zu Delphi code zu sein[1] und da die Sprache von vornherein auf die CLR getrimmt ist, wüsste ich nicht was da an Problemen auftauchen sollte.
Sie sind auch ein wenig zurückhaltend was Features angeht, die komplett "unpascalish" wären: Ich habe sie z.Bsp. bis heute nicht von +=, -=, ++, -- überzeugen können. (habe es aber schon vor langem aufgegeben. ;) )
Wobei += und -= nur für Events vorhanden waren.

[1] das beschränkt sich aber eigentlich nur auf

• namespace->unit
• new X -> X.Create (aber auch NUR Create, keine anders benannten Kontruktoren sind erlaubt)
• aliaslose with-clauses

Zitat:

Was ich aber sehr fair finde ist das:

Zitat:

Chrome 1.5 is a free update for all existing users of Chrome 1.0.

Es heißt auch nur aus diesem Grund 1.5 und nicht 2. :mrgreen:

Zitat:

Eine deutsche Version fände ich auch nicht schlecht :)

Wird so schnell nicht passieren, lohnt sich einfach nicht. Vor allem da du ohne Englischkenntnisse auch in ROs support NGs auf wenig (sprachl.) Verständis stoßen wirst.


@MrSpock
Viele von Delphis Einschränkungen sind IMO nur vermarktet als qualitätsfördernde Strenge.
Gäbe es den Zwang, Variablen nur in der Var section deklarieren zu können, wirklich nur um saubereren Code zu erzwingen, hätte es niemals ein with in dieser kranken Form gegeben. ;)
Ich denke eher, dass die Investition in einen Compiler, der dazu in der Lage wäre, gescheut wurde.

Aber Chrome ist IMO keine Sprache für Anfänger, schlicht und ergreifend weil ich keine richtige (also mit Ausnahme von KPL ;) ) .Net Sprache als anfängertauglich bezeichnen würde.

[Frickeldrecktuxer_TM]

Zitat:

Zitat von MrSpock

Hört sich an, wie irgendwann bin ich so gut, dass ich keinen sauberen Code mehr schreiben muss.

Nein, eher so wie "Irgendwann bin ich so gut, daß ich sauberen Code schreibe, und nicht mein Compiler." ;-)

Zitat:

Zitat von MrSpock

Ich programmiere jetzt schon seit über 20 Jahre und habe mich durch Pascal / Delphi nie eingeschränkt gefühlt, glaube aber gut wartbaren Code zu schreiben.Sinnvolle Erweiterungen hat es ja im Laufe der Zeit auch in Delphi's Pascal gegeben.

Einige Features des Delphi-Refactorings sind durch die Sprache erst notwendig geworden. Zum Beispiel waren alle ganz aus dem Häuschen, als es hieß, die IDE würde jetzt lokale Variablen automatisch im Funktionskopf ergänzen, wenn man sie weiter unten einführt, und zwar ohne daß man selbst nach oben scrollt und die Variablen entsprechend selber nachträgt.
Und ich persönlich finde es in komplexen Funktionen deutlich unübersichtlicher, alle Variablen im Funktionskopf zu haben. Man nehme zum Beispiel eine Nachrichtenbehandlungsroutine:

Code:

void myhandler(message_t somemmessage)
{
  switch (somemmessage.type)
  {
  TYPE_1:
    {
      int i; // und weitere Variablen, die ich nur in dem Fall benötige, wenn ich Nachrichten vom Typ 1 erhalte
      break;
    }
  TYPE_2:
    {
      int i; // und weitere Variablen, die ich nur in dem Fall benötige, wenn ich Nachrichten vom Typ 2 erhalte
      break;
    }
  TYPE_3
    {
      int i; // und weitere Variablen, die ich nur in dem Fall benötige, wenn ich Nachrichten vom Typ 3 erhalte
      break;
    }
  TYPE_4:
    {
      int i; // und weitere Variablen, die ich nur in dem Fall benötige, wenn ich Nachrichten vom Typ 4 erhalte
      break;
    }
  TYPE_5:
    {
      int i; // und weitere Variablen, die ich nur in dem Fall benötige, wenn ich Nachrichten vom Typ 5 erhalte
      break;
    }
  default:
    break;
  }
}

Mit passenden Optimierungen hältst du dir damit auch noch den Stack sauber. Angenommen ich bräuchte für jede Nachricht 5 Variablen unterschiedlichen Typs. Warum sollte ich mir meinen Funktionskopf mit 25 Variablen zukleistern? So kann ich wunderbar die Variablen dort deklarieren, wo ich sie benötige. Nur dort sind sie gültig und Objekte werden automatisch freigegeben, sobald der Scope verlassen wird (okay, sowas kennt Delphi nicht, aber das ist ja ein anderes Thema).
Vom Entwickler wird bezüglich der Wartbarkeit nur verlangt, daß er nicht einfach "irgendwo" die Variablen deklariert, dann das wäre wirklich unübersichtlich. Aber der Entwickler hat so ein feineres Werkzeug um zu bestimmen, wie lange die Variablen überhaupt existieren und bezüglich der Wartbarkeit den Variablen einen Block zuzuordnen, zu dem sie gehören.

Dieses Märchen, daß die Pascal-Syntax automatisch für wartbaren Code sorgt und daß alle anderen Programmiersprachen dadurch automatisch böhse[tm] sind, habe ich oft genug gehört, als daß ich es noch ernstnehmen würde. Wartbarer Code liegt immer am Entwickler. Wer mit C oder C++ keinen wartbaren Code schreibt, benutzt sein Werkzeug falsch.

[Christian S.]

Wie kann sich denn das:

Zitat:

Zitat von Christian S.

Aber irgendwann ist man aus dem Stadium heraus, dass man einen Compiler braucht, der einem Vorschriften macht, um lesbaren Code zu erzeugen.

Wie das:

Zitat:

Zitat von MrSpock

Hört sich an, wie irgendwann bin ich so gut, dass ich keinen sauberen Code mehr schreiben muss.

anhören, ohne dass der Zuhörer das wirklich so verstehen will?

Zitat:

Zitat von MrSpock

Ich programmiere jetzt schon seit über 20 Jahre und habe mich durch Pascal / Delphi nie eingeschränkt gefühlt, glaube aber gut wartbaren Code zu schreiben.

Dann ist es für Dich gut und richtig, bei Delphi zu bleiben. Wie ich obne schon schrieb: Jedem das, was ihm am Besten gefällt. Es heisst aber nicht, dass man nicht auch in Chrome gut wartbaren Code schreiben kann. Es erfordert halt eine gewisse Disziplin des Programmierers. Das ist z.B. die Disziplin, die dazu führt, dass man in Delphiprogrammen kaum Goto-Anweisungen sieht, obwohl die Sprache es zur Verfügung stellt.

[Hansa]

Zitat:

Zitat von MrSpock

..Hört sich an, wie irgendwann bin ich so gut, dass ich keinen sauberen Code mehr schreiben muss...

:lol: Schlimmer noch : einige fühlen sich offensichtich geradezu ermuntert, die Fehler von C-Programmierern nachmachen zu müssen. Ist halt momentan in. :mrgreen: Ich kann nur sagen : es lebe die Freiheit, die nur die Inkompatibilität zur Folge hat. 8) Und die Tatsache, daß man nicht alles so machen muß, was man kann, bedeutet nach Murphy : es wird doch gemacht werden ! Elvis weiß zwar sowieso nicht, was er will 8) , aber was jetzt ? Kommt es auf die IDE an, oder auf die Programmiersprachen-Syntax ? Erst wird Delphi auf diese "Mist-IDE" reduziert und nun isr die ziemlich egal, denn die Syntax von Chrome ist ja so viel besser und bietet viel mehr ? :shock: Das soll verstehen, wer will.

Einige "Erweiterungen" durch Chrome sehe ich zumindest als klare Nachteile an. Und was nützt es mir, wenn ich sie dann gar nicht brauche oder vorsichtshalber nicht benutze ? Übrig bleiben mehr Nach- als Vorteile. Meine Meinung dazu ! Solche Threads führen sowieso zu keinem Ergebnis.

[Daniel]

Zitat:

Zitat von Hansa

Solche Threads führen sowieso zu keinem Ergebnis.

Definitiv falsch und nicht zuende gedacht.

Christian hatte doch selbst schon geschrieben, dass es sich um einen Blick über den Teller-Rand handelt und das im Endeffekt jeder für sich entscheiden müsse. Es wäre schön, wenn Ihr wieder zu einer sachlichen (!) Bewertung zurückfinden könntet.

Ganz nebenbei geht es hier nicht um "Highlander" - es kann also auch mehr als einen geben. ;-)

[Frickeldrecktuxer_TM]

Zitat:

Zitat von Hansa

einige fühlen sich offensichtich geradezu ermuntert, die Fehler von C-Programmierern nachmachen zu müssen.

Welche "Fehler von C-Programmierern"? Und wer fühlt sich dazu ermuntert?

Zitat:

Zitat von Hansa

Ich kann nur sagen : es lebe die Freiheit, die nur die Inkompatibilität zur Folge hat.

Na also, dann leb' du weiterhin eingeschränkt (beinahe hätte ich "beschränkt" geschrieben :mrgreen:), aber lass Christian S. die Freiheit, eine Sprache zu benutzen, die ihm deutlich mehr Vorteile bietet, weil er weiß, wie er damit umgehen muss.

Zitat:

Zitat von Hansa

Kommt es auf die IDE an, oder auf die Programmiersprachen-Syntax ? Erst wird Delphi auf diese "Mist-IDE" reduziert und nun isr die ziemlich egal, denn die Syntax von Chrome ist ja so viel besser und bietet viel mehr ? :shock: Das soll verstehen, wer will.

Dir ist aber schon bewusst, daß Chrome nicht mit Delphi/BDS funktioniert, sondern nur im VS? Wenn jemand über die "Mist-IDE" meckert, wie du es ausdrückst, ist es nur konsequent, sich für Chrome oder andere Sprachen zu interessieren, die nicht "Mist" sind. Außerdem hat nicht jeder Delphi nur auf die IDE reduziert. Elvis, wenn du ihn schon nennst, hat beispielsweise immer gesagt, daß auch die Sprache selbst genug Mängel aufweist.
Also, um deine Frage zu beantworten: Ja, die Syntax von Chrome ist für einige so viel besser und bietet (faktisch, nicht für einige) viel mehr, deswegen kann Delphi aber weiterhin eine "Mist-IDE" sein, weil das eine das andere nicht ausschließt. Chome hat schließlich nichts mit Delphi oder Borland gemein.

Zitat:

Zitat von Hansa

Einige "Erweiterungen" durch Chrome sehe ich zumindest als klare Nachteile an.

Welche? Besagte Variablendeklaration zwischen begin und end? Warum ist das ein Nachteil für jemanden, der damit umgehen kann?

Zitat:

Zitat von Hansa

Und was nützt es mir, wenn ich sie dann gar nicht brauche oder vorsichtshalber nicht benutze ?

Du hast die Freiheit (da ist sie wieder), die zusätzlichen Features einzusetzen, wenn du einmal reif genug sein wirst, dies sinnvoll zu tun.

Zitat:

Zitat von Hansa

Übrig bleiben mehr Nach- als Vorteile.

Benutzt du eigentlich Messer? Es ist ein ganz klarer Nachteil, daß man damit Menschen umbringen kann. Und so unglaublich nützlich sind die verbleibenden Vorteile von Messern ja auch nicht, schließlich kann ich meine Nahrung auch mit den Zähnen zerkleinern. Es bleiben also mehr Nach- als Vorteile beim Gebrauch von Messern. Ich werde gleich eine Petition einreichen, die die Benutzung von Messern EU-weit untersagt!

[lizardking]

Zitat:

Zitat von Christian S.

Ein guter Punkt, um zum nächsten Beispiel zu kommen, wo der Compiler Arbeit übernimmt. Oft kommt es vor, dass eine Property einfach nur ein privates Feld kapselt, also gar keine get- und set-Methoden vorhanden sind.

Hier hilft Chrome, den ewig gleichen Standardcode zu vermeiden, indem es folgende Syntax erlaubt:

Delphi-Quellcode:

type
  TFoo = public class
  public
    property aProp : String;
  end;

Mehr ist nicht nötig, um eine Property anzulegen, der Rest wird implizit deklariert. (Obiges Beispiel zeigt ein weiteres Chrome-Feature: Typensichtbarkeit wird vollständig unterstützt.)

Ein Beispiel fuer ein Feature, was mich persoenlich stoeren wuerde. In Delphi saehe es ja so aus :

Delphi-Quellcode:

type
  TFoo = public class
  private
    FProp: String;
  public
    property Prop : String read FProp write FProp;
  end;

Jetzt hab ich ein wenig mehr Code, wenn ich aber in der Klasse TFoo arbeite, weiss ich immer genau was passiert. Wenn ich dort naemlich "fremden" Code von Kollegen durchgehe, kann ich bei jeder Zuweisung erstmal nachschauen, ob nicht eine Setter-Methode noch mehr macht als nur die Variable zu setzen. Wenn sich aber jeder daran haelt innerhalb der Klasse nur auf die Feldvariablen zuzugreifen, kann ich auf einen Blick ausschliessen, dass noch irgendwas sonst passiert.

Wenn mich diese klare Trennung von Feldvariablen und Properties nicht sonderlich kuemmert, dann kann ich zur Not auch einfach die Variablen als public deklarieren ;)

Gruss, Lizzy

[Daniel]

@Hansa & Frickeldrecktuxer_TM: Gleich sperre ich euch beide aus diesem Thread aus.
:wall:


Meine Güte - seit Jahren knallt Ihr beiden immer wieder aneinander und lernt nichts daraus. Wieviele Threads habt Ihr beiden mit Euren kindischen Kleinkriegen bereits zerstört? Ist das Geltungsbewusstsein tatsächlich so groß, dass die sachliche Diskussion egal ist? Wenn dies der Fall ist, solltest Du über Konsequenzen nachdenken.

Ich werde beide Beiträge gleich deaktivieren und bitte darum, diese Diskussion sachlich fortzuführen.


[edit]
Mal sehen, vielleicht geht's ja auch ohne deaktivieren.

@Rest: Bitte ignoriert die beiden. :wall:
[/edit]

[edit=alcaeus]Name korrigiert ;) Mfg, alcaeus[/edit]

[Elvis]

Zitat:

Zitat von lizardking

Ein Beispiel fuer ein Feature, was mich persoenlich stoeren wuerde. In Delphi saehe es ja so aus :

Delphi-Quellcode:

type
  TFoo = public class
  private
    FProp: String;
  public
    property Prop : String read FProp write FProp;
  end;

Du hast die Möglichkeit auch in Chrome. Sie macht nur wenig Sinn, da das Feld nur sinnlos in Editor und Code completion rumliegen würde.
In so einem Fall wird der Compiler _innerhalb_ der Klasse das Feld benutzen und zwar solange das Feld entweder implizit angelegt(wie in Christians Code) oder einfach einen inline setter hat (wie in deinem Code).

Zitat:

Wenn mich diese klare Trennung von Feldvariablen und Properties nicht sonderlich kuemmert, dann kann ich zur Not auch einfach die Variablen als public deklarieren ;)

Da Chrome aber eine .Net Sprache ist, drehen sich die Räder ein wenig anders.
Zugriff auf Felder ist da mehr ein PITA: Class invariants können nicht bei Änderungen ablaufen, außerdem würde eine später eingefügte Property mit gleichem Typ & Namen einen breaking Change bedeuten (auf IL Ebene[1]). Nicht zu vergessen, dass DataBinding nur auf Properties funktioniert.
Es gibt nur seeehr wenige Fälle, in denen man ein Feld öffentlich sichtbar machen sollte. Die meisten .Net Devs werden solch einen Fall wohl nie erleben.

Zitat:

Jetzt hab ich ein wenig mehr Code, wenn ich aber in der Klasse TFoo arbeite, weiss ich immer genau was passiert. Wenn ich dort naemlich "fremden" Code von Kollegen durchgehe, kann ich bei jeder Zuweisung erstmal nachschauen, ob nicht eine Setter-Methode noch mehr macht als nur die Variable zu setzen.

Für sowas gibt es in Object pascal interface sections, eine bessere Zusammenfassung einer Klasse wirst du so schnell nicht kriegen. ;)

Zitat:

Wenn sich aber jeder daran haelt innerhalb der Klasse nur auf die Feldvariablen zuzugreifen, kann ich auf einen Blick ausschliessen, dass noch irgendwas sonst passiert.

Wenn sich jeder daran halten würde hättest du wirlich Pech. Du könntest keine Events auslösen auf die sich DataBinding registriert(siehe INotifyPropertyChange im .Net SDK) oder die notwendig sind, damit andere Teile deiner App von dieser Änderung erfahren können. Deine Syntax oben benutze ich immer dann, wenn ich tatsächlich irgendwo direkt auf das Feld schreiben will oder wenn ich einen speziellen Setter implementieren will.
Da ich aber vorher schon die implizite Property stehen hatte ist das kein breaking Change mehr.[1]

[1]Es sind einfach ganz andere IL OpCodes und Abläufe im Spiel ob man nun ldfld XXX oder call get_XXX auszuführt. -> Jede Assembly, die deine Binary benutzt wird definitv alle Viere von sich strecken wenn du von einem öffentlichen/protected Feld auf eine Property wechselst.

btw:@Daniel
Mit ein wenig Stolz kann ich von mir behaupten, dem unwiderstehlichen Drang, dem großen H einen Einlauf zu verpassen, erfolgreich widerstanden zu haben :stupid:

[Daniel]

Zitat:

Zitat von Elvis

btw:@Daniel
Mit ein wenig Stolz kann ich von mir behaupten, dem unwiderstehlichen Drang, dem großen H einen Einlauf zu verpassen, erfolgreich widerstanden zu haben :stupid:

Das habe ich freudig zur Kenntnis genommen. :-)

[SubData]

Zitat:

Zitat von Christian S.

Aber irgendwann ist man aus dem Stadium heraus, dass man einen Compiler braucht, der einem Vorschriften macht, um lesbaren Code zu erzeugen.

Für mich hört sich das an, wie: Irgendwann kann man auch sauberen Code schreiben, ohne dass einem der Compiler dabei helfen muss ^^

[MrSpock]

Hallo SubData,

ja, die Aussage hört sich so an. Ich glaube nur einfach nicht daran. Die Disziplin wird in der Regel leider nur von sehr wenigen Programmierern eingehalten. Tools, die die Disziplin "fordern" -und dazu zählen auch Compiler- sind deshalb sinnvoll. Gute Programmierer werden häufig als Programmierer betrachtet, die schnell funktionierenden Code erstellen. Der Grad der Einhaltung von Regeln wird dabei häufig nur am Rand betrachtet.

Von daher ist ein Blick über den Tellerrand ja durchaus angebracht. Man sollte aber wirklich die Vorteile und die Nachteile auch gerade bezüglich der Wartbarkeit des entstehenden Codes sorgfältig gegeneinander abwägen. Sollte nach einem solchen Prozess die Vorteile z.B. von Chrome überwiegen, dann sollte man sich dafür entscheiden, sonst dagegen. Ein Blick über den Tellerrand hat sich dann in jedem Fall gelohnt, entweder zur Bestätigung des bisherigen Tools, oder aber zur Auswahl eines neuen.

[Daniel G]

Zitat:

Zitat von MrSpock

Gute Programmierer werden häufig als Programmierer betrachtet, die schnell funktionierenden Code erstellen.

Dann bleibe ich lieber ein "schlechter Programmierer", wenn im Gegenzug die Leute kapieren, was ich mir da zusammengeschrieben habe.
Bilde ich mir das eigentlich nur ein, oder ist die Chrome - IDE deutlich günstiger als die Delphi - IDE? (um jetzt mal auf einen ökonomischen Punkt zu kommen... :zwinker: )

[Elvis]

Zitat:

Zitat von Daniel G

Bilde ich mir das eigentlich nur ein, oder ist die Chrome - IDE deutlich günstiger als die Delphi - IDE? (um jetzt mal auf einen ökonomischen Punkt zu kommen... :zwinker: )

Wo hast du eine Chrome IDE gesehen? :shock:
Chrome selbst kostet für Ex-(.Net-)Delphianer 150€, dazu kommt noch ein VS05 Standard mit nochmal 300€ (keine Express, da die keine AddIns laden können).
Chrome ist also eine weitere Sprache im VS, es hat keine IDE.

[mkinzler]

Zitat:

Bilde ich mir das eigentlich nur ein, oder ist die Chrome - IDE deutlich günstiger als die Delphi - IDE? (um jetzt mal auf einen ökonomischen Punkt zu kommen... Zwinkern )

Die CLI-Edition kosten sogar nix. Aber da Chrome keine eigene IDE hat muß man hier noch die KKosten von VS2005 hinzurechnen. Mit der express löüft Chrome nicht. (zumindest nicht die Trial-Version)

[Elvis]

Zitat:

Zitat von mkinzler

Zitat:

Bilde ich mir das eigentlich nur ein, oder ist die Chrome - IDE deutlich günstiger als die Delphi - IDE? (um jetzt mal auf einen ökonomischen Punkt zu kommen... Zwinkern )

Die CLI-Edition kosten sogar nix.

Dürfen auch nix kosten. Sonst würden einige mit ihren ASPX Spieereien große Probleme kriegen.
Der IIS/Cassini/Apache braucht schon einen CodeDOM/Compiler um Codebehind und inline Code verweben zu können. (Wobei man das auch statisch kompiliert lösen kann/sollte)

Deshalb sieht man bei Delphi.Net ASPX-Dateien language="C#"

[Christian S.]

Zitat:

Zitat von MrSpock

ja, die Aussage hört sich so an. Ich glaube nur einfach nicht daran. Die Disziplin wird in der Regel leider nur von sehr wenigen Programmierern eingehalten.

Da ich als Hobby-Programmierer meist alleine arbeite, ist das ein Punkt, der für mich kaum von Belang ist, weil ich weiß, dass ich die Disziplin habe. Plant man die Anschaffung eines Compilers für eine große Gruppe (z.B. in einer Firma), ist das sicherlich ein Punkt, den man bedenken muss. (Unabhängig davon, wie meine Einschätzung davon ist, das ist auch nicht so wichtig.)

Zitat:

Zitat von MrSpock

Von daher ist ein Blick über den Tellerrand ja durchaus angebracht. Man sollte aber wirklich die Vorteile und die Nachteile auch gerade bezüglich der Wartbarkeit des entstehenden Codes sorgfältig gegeneinander abwägen. Sollte nach einem solchen Prozess die Vorteile z.B. von Chrome überwiegen, dann sollte man sich dafür entscheiden, sonst dagegen. Ein Blick über den Tellerrand hat sich dann in jedem Fall gelohnt, entweder zur Bestätigung des bisherigen Tools, oder aber zur Auswahl eines neuen.

:thumb:

@Preis für IDE: Insgesamt kommt man aber immer noch deutlich günstiger weg als bei Delphi. Man hat zwar dann auch die anderen Delphi-Personalities nicht, dafür sind andere Dinge mit im Paket. Muss man halt schauen, was man braucht ;-)

[Daniel G]

Zitat:

Zitat von Elvis

Chrome ist also eine weitere Sprache im VS, es hat keine IDE.

So langsam versteh' ich's.... :duck:

[Frickeldrecktuxer_TM]

Zitat:

Zitat von MrSpock

Ich glaube nur einfach nicht daran. Die Disziplin wird in der Regel leider nur von sehr wenigen Programmierern eingehalten. Tools, die die Disziplin "fordern" -und dazu zählen auch Compiler- sind deshalb sinnvoll.

Für mich sehe ich das grundsätzlich so wie Christian: Ich kann übersichtlichen Code schreiben und tue das auch.
Ich vertrete aber auch die gewagte These, daß man sich bei der Entwicklung in einem Team ohnehin an bestimmte Regeln halten muss, die über das hinausgehen, was der Delphi-Compiler einem auferlegt. Das fängt bei Naming-Conventions an (ungarische Notation jo oder no, immer einen Getter/Setter oder nur on demand, Klassenfelder mit oder ohne F, Unterstrich oder was auch immer davor, ...) und geht beim allgemeinen Klassendesign weiter (möglichst generisch oder möglichst wenig Codezeilen). Brauchbare Code-Formatierung ist da nur eine weitere Regel unter vielen, an die sich Entwickler im Team halten müssen, ob es nun die Einrückung mit Tab, zwei, vier oder acht Leerzeichen ist, oder ob man Variablendeklarationen am Anfang des Blockes (nicht Funktion!) sammelt oder wie Rosinen im Code verteilt. Ich würde durchaus sagen, daß die Teamfähigkeit auch ein Qualitätsmerkmal eines Entwicklers ist, der in einem Team entwickeln möchte. Und dazu zählt auch, ob er sich an allgemeine Regeln (die wohl alle für sinnvoll halten, ich kenne niemanden, der es gut findet, Variablendeklarationen im Code zu verteilen) hält, oder nicht und somit unlesbaren Code produziert.
Ein "guter" (Team-)Entwickler hält sich also an die Vereinbarungen und produziert Code, den er auch am nächsten Tag noch versteht.

Zitat:

Zitat von Christian S.

@Preis für IDE: Insgesamt kommt man aber immer noch deutlich günstiger weg als bei Delphi. Man hat zwar dann auch die anderen Delphi-Personalities nicht, dafür sind andere Dinge mit im Paket. Muss man halt schauen, was man braucht ;-)

Welche Delphi-Personalities außer Delphi/Win32 gibt es denn zu vermissen? Das VS kann C#, C++ und Managed C++, mehr kann das BDS auch nicht. Mir fällt also nur die Delphi/Win32-Personality ein, die man vermissen könnte, wenn man C++ nicht mag.

[Alexander]

Der Preis ist wirklich erstaunlich niedrig. Ich habe auch schon mehrmals überlegt (auch früher schon, also Robert_G mehrfach es lobend erwähnt hat). Selbst 300 € sind im Vergleich zur Prof-Version von Delphi nicht wirklich viel. Da kostet ja das Update schon 400 €. Zumal die Preispolitik wie gesagt der Firma mir recht fair erscheint. Aber das kann sich (wie bei Borland) ja noch ändern :mrgreen:. Ein bewertes Markenprodukt kostet eben :tongue: (soll nicht heißen, dass es besser ist. Kann ich nicht bewerten)

[Lemmy1]

Ich wollte auch mal meine 5 €-Ct dazu werfen: Ich finde Chrome eine schöne Sprache, die in .Net im Gegensatz zu Delphi auch wirklich zu Hause ist. Aber der Hauptvorteil von Delphi ist für mich trotzdem die Möglichkeit, mit demselben Code Win32 und .Net zu unterstützen. Das ist einmalig und mir auch Geld wert.

Habe für eine Win32 Software z.B. einen Licensekey-Generator unter ASP.Net geschrieben. Das läuft nun alles vollautomatisiert und mit einer Code-Basis ab. Sowas ist mein keiner anderen Sprache so gut möglich.

Ich fände es aber trotzdem schön, wenn Borland sich ein paar gute Ideen von Chrome abschauen würde :)

[Boombuler]

Hi @ all

So ich nutze Privat auch seit ca 2 Wochen Chrome. Momentan kann ich zu Chrome folgendes sagen:

Pro:
- .NET 2.0
- Einige nette Sprachfeatures
- Kostenloser Compiler
- Compact Framework (auch wenn ich noch nicht rausgefunden habe wie... angeblich gehts ja ;) )

Kontra:
- Das meiste meines "alten" Delphi Codes muss aufwendig portiert werden da es keine VCL gibt
- Ich habe noch keine brauchbare Chrome Community gefunden :(
- "Toter Code" sollte das Chrome Projekt eingestellt werden.

Und was diese Streiterei über die Sprachfeatures angeht:
Es wird niemand gezwungen diese zu nutzen und in einem Entwicklerteam muss es einfach gewisse Designregeln geben.

Ich denke der Hauptgrund für mich war einfach .NET 2.0 Code in Pascal Syntax zu haben, da ich der Überzeugung bin, dass kein C-Derivat jemals eine so leicht zu lesende Syntax haben wird wie ein Pascal-Derivat!

Merke: Pascal dokumentiert sich fast schon selbst! (Bitte nicht hauen is nich ganz ernst gemeint!)


Greetz
Boombuler

[sh17]

Zitat:

Zitat von Boombuler

da es keine VCL gibt

auch besser so :-D

Zitat:

Zitat von Boombuler

- Ich habe noch keine brauchbare Chrome Community gefunden :(

Na die Newsgroups halt nur. Ansonsten kommt hier mal noch was http://www.chromeportal.com/

Zitat:

Zitat von Boombuler

- "Toter Code" sollte das Chrome Projekt eingestellt werden.

das macht der Marc nicht :duck:

[Elvis]

Zitat:

Zitat von Boombuler

Kontra:
- Das meiste meines "alten" Delphi Codes muss aufwendig portiert werden da es keine VCL gibt

Schaue dir mal ShineOn an, oder versuche die VCL.Net von Borland übergangsweise einzubinden bis du weit genug von Win32 weg bist, damit ShineOn übernehmen kann.

Zitat:

- Ich habe noch keine brauchbare Chrome Community gefunden :(

auf news.remobjects.public.Chrome wirst du schon Hilfe finden. Falls die Frage nicht zuuu langweilig ist, antworte vllt sogar ich. :stupid: :mrgreen:

Zitat:

- "Toter Code" sollte das Chrome Projekt eingestellt werden.

RO hat schon des öfteren erklärt, dass Chrome sofort Open source wird, falls RO warum auch immer die Tore schließen müsste.

Zitat:

Ich denke der Hauptgrund für mich war einfach .NET 2.0 Code in Pascal Syntax zu haben, da ich der Überzeugung bin, dass kein C-Derivat jemals eine so leicht zu lesende Syntax haben wird wie ein Pascal-Derivat!

Merke: Pascal dokumentiert sich fast schon selbst! (Bitte nicht hauen is nich ganz ernst gemeint!)

Wobei ich eigentlich nur die deklarative Syntax von ObjectPascal als so leserlich empfinde. Vanilla Pascal nimmt sich gegenüber C nicht viel, IMHO.

[Alexander]

Cool wäre ein Service wie der von Borland's BabelCode, der mir Delphi.NET Code in Chrome-Code umwandelt. Die beiden scheinen sich ja doch ein wenig zu unterscheiden :).
Gibt es eigentlich eine Art SharpDevelop für Chrome? Ich habe nämlich nur die Express Version vom VS. Genial wäre halt eine IDE, die direkt auf dem kostenlosen Chrome Compiler aufbaut. Dann hat man keine Kosten mehr :). Und zum Ausprobieren reicht es alle mal.
Wenn man das VS hat, ist Chrome aber eigentlich recht günstig ;)

[Boombuler]

Zitat:

Zitat von Elvis

Zitat:

Zitat von Boombuler

Kontra:
- Das meiste meines "alten" Delphi Codes muss aufwendig portiert werden da es keine VCL gibt

Schaue dir mal ShineOn an, oder versuche die VCL.Net von Borland übergangsweise einzubinden bis du weit genug von Win32 weg bist, damit ShineOn übernehmen kann.

Ja ne wennn wollt ich direkt von VCL weg. Ist zwar am Anfang n bischen arbeit aber der Schritt kommt so oder so!

Zitat:

Zitat von Elvis

Zitat:

- Ich habe noch keine brauchbare Chrome Community gefunden :(

auf news.remobjects.public.Chrome wirst du schon Hilfe finden. Falls die Frage nicht zuuu langweilig ist, antworte vllt sogar ich. :stupid: :mrgreen:

Firma dankt!

Zitat:

Zitat von Elvis

Zitat:

- "Toter Code" sollte das Chrome Projekt eingestellt werden.

RO hat schon des öfteren erklärt, dass Chrome sofort Open source wird, falls RO warum auch immer die Tore schließen müsste.

Lass mich raten das haben die in oben genannter Newsgroup von der ich noch nix wusste erzählt? ;)

Greetz
Boombuler

[Elvis]

Zitat:

Zitat von Alexander

Cool wäre ein Service wie der von Borland's BabelCode, der mir Delphi.NET Code in Chrome-Code umwandelt. Die beiden scheinen sich ja doch ein wenig zu unterscheiden :).

Wäre mal 'ne nette Idee für's WE, falls ich nicht zum Fussball genötigt werde. :zwinker:

Zitat:

Gibt es eigentlich eine Art SharpDevelop für Chrome?

Nope, gibt es nicht.
Ich selbst hatte mal damit angefangen, aber in der Zwischenzeit wurde das VS AddIn besser und ich musste zwischen dem zeitichen Aufwand und dem wirklichen Nutzen für mich abwägen. ;)
Ich weiß aber von ein paar anderen, die auch an einem #D bidning arbeiten, aber sicher nicht genannt werden wollen. ;)

Zitat:

Wenn man das VS hat, ist Chrome aber eigentlich recht günstig ;)

Schaue mal was dich ein VS05 Standard als EDU kostet, die Chrome EDU kommt, glaube ich, auf 50-60€.
Wenn die Preise der EDUs wie beim VS03 sind, kämst du mit beidem auf ~ 200-220€.