Zitat von Sherlock:

Dank DDevExtensions ...

Ja, da geht Vieles.

Mich wundert es, daß SuperZoom (hatte vorhin umsonst doppelt geklickt) und Co. noch nicht direkt übernommen wurden.

Zitat von Mavarik:

Ale Desktop-VCL Entwickler würde ich überhaupt keine Updates kaufen und wenn überhaupt immer 2-3 Versionen überspringen...

Du brauchst keinen Unicode? Nimm D2007 immer noch die beste IDE
Du brauchst Unicode, anonyme Proceduren und Generics nimm eine XE Version...
Threads zu "kompliziert" nimm XE7 mit Parallel Library.

Sorry, das ist mir zu einfach.. Soap mit Delphi 7 gemacht? Auch mit den "Backports" von Delphi 2007 gibt es da noch viele schwarze Löcher bzw. Fehler. Wird imho erst später deutlich besser. Ok, da kann man oft auch eingreifen - das Teil macht aber regelm. Blödsinn...

Von den ganzen Spracherweiterungen (Classhelpers, Recordhelpers) die Code besser lesbar machen will ich noch gar nicht anfangen...

Die Grundaussage passt aber.

Wer mit Delphi mobil entwickeln will braucht ein Abo und muss alle Sprünge mitmachen. Das liegt an den Änderungen der mobilen Systeme selbst (für die Emba nichts kann) und an Bugs, die Emba verschuldet und nicht zeitnah bereinigt.

Wer nur mit der VCL arbeitet kann getrost zuschauen und aller paar Jahre mal ein Update kaufen (falls es mal interessante neue Features gibt und die neue IDE stabil erscheint).

Wenn man aber die Module trennen würde (Compiler+Linker, Debugger, RTL/VCL/FMX, usw.) dann wäre es bestimmt auch möglich viele "nötige" Anpassungen an neue/geänderte Systeme auch als Update für ältere Versionen bereitzustellen.
Man könnte doch bestimmt auch wichtige Anpassungen/Bugfixes in ältere IDEs mergen und dort ebenfalls länger als 2-3 Monate nach Erscheinen als Update rausbringen, aber das hat sich ja nun erledigt, denn das verkauft man nun als neues Subscription-Feature.

z.B. im Android-Studio und Android-AVD-Manager läd man sich dann doch auch einfach nur das passende SDK runter und fertig.
Gut, daß man jetzt urplötzlich noch schnell einen neuen Compiler brauchte und damit ein neues Delphi, das lässt sich schwer vermeiden, aber sonst...

Zitat von Lemmy:

Sorry, das ist mir zu einfach.. Soap mit Delphi 7 gemacht? Auch mit den "Backports" von Delphi 2007 gibt es da noch viele schwarze Löcher bzw. Fehler.

Ich erinnere mich dunkel... Da gab es in D7 aber einen SOAP Fehler der ist in D2007 nicht mehr drin...

Daher nehme ich für SOAP immer D2007!

Zitat von Daniel:

damit hier kein zweites Torry.net heranwächst.

Was ist denn das Problem mit Torry.net und ähnlichen Seiten?

Man könnte ja so ähnlich wie bei Firefox-Erweiterungen Angaben zur Kompatibilität zu Delphi-Versionen machen. Außerdem eine Historie wie sehr die Quellen gepflegt und aktuell gehalten wurden. Daraus lässt sich dann Verlässlichkeit ableiten.

Große Firma, Community oder einzelne Entwickler, das alleine war meiner Erfahrung nach nicht ein guter Indikator für Verlässlichkeit. Da schon eher die Motivation oder das Interesse der Projektbetreuer (die sich auch bei Firmen schnell ändern kann und in der Vergangenheit geändert hat).

Sehr nützlich wäre außerdem dass man selbst Quellen angeben kann, falls man selbst Komponentenpackete installieren will, oder das Installieren von eigenen nicht öffentlichen Komponenten über "Getit" automatisieren will.

Wäre sehr nützlich um schnell eine Neuinstallation von Delphi und Co durchzuführen oder ähnliche Umgebungen für Teammitglieder zu schaffen.

Ich denke es wäre sehr nützlich den Benutzer, wie bei apt-get, externe "Repositories" hinzufügen zu lassen. Z.b. über einen Link der dann automatisch den Delphikomponenteninstaller aufruft.
Man kann ja eventuell zwischen offiziellen (von Emb gepflegt bzw. geprüft) und anderen unterscheiden und darauf hinweisen.

Seit gestern abend sind die JEDI-Libs JCL und JVCL für XE8 auf Github verfügbar:

JCL Revision 9509: https://github.com/project-jedi/jcl
JVCL Revision 10968: https://github.com/project-jedi/jvcl

Build lief bis auf eine Warning bei JVCL unter XE7 und XE8 ohne Probleme.

Zitat von Daniel:

Für einen Individual-Entwickler einer ... sagen wir ... "Durchschnittskomponente" sehe ich da wenig Chancen - und als GetIt-Nutzer finde ich diese grobe Richtung auch prinzipiell richtig.

Ich finde das sehr schade. Wenn ich mir anschaue, was ich im .NET-Umfeld über NuGet-Packages alles beziehen kann, dann bringt mich der GetIt-Paketmanager nicht weiter. Unter Delphi wird es sich dann wohl weiterhin wie in den neunziger Jahren anfühlen, wenn man mit Fremdbibliotheken arbeitet.

Ich habe mir XE8 jetzt auch mal angeschaut und bin entsetzt. Castalia wirkt reingeklatscht. In der Feature-Matrix wird Castalia in etwa zehn Einträgen direkt oder indirekt erwähnt. Die Refactoring-Methoden sind weiterhin unbrauchbar. Der Test in einem realen großen Projekt einen Methoden-Parameter um zu benennen, führt zuverlässig zu einem IDE-Absturz. Die "Extract-Method"-Funktion produziert weiterhin Müll. Was bringt mir eine Prozedur mit einem Var-Parameter? Wer will denn damit arbeiten?
Positiv ist, dass die IDE nicht mehr wegen zu wenig Speicher abstürzt, wenn eine große Projektgruppe (>=3 Echte-Welt-Projekte) kompiliert. Das war es dann aber auch. Die Liste gefixter Bugs beinhaltet nur einen Bruchteil der jahre alten Compiler- und VCL-Fehler.
Bei der DUnitX-Integration war ich zunächst sehr erfreut. Ich hoffte es kommt endlich ein Testrunner, der in die IDE integriert ist und vielleicht eine CodeCoverage-Analyse für meine Testfälle. Stattdessen gibt es ein Projekttemplate für den DUnitX-Command-Line-Testrunner.
Was gibt es also für große Neuerungen für einen Nur-Windows-Entwickler?
- Ein minimalistischer nicht offener Paketmanager
- Ein vorinstalliertes Editor-Plugin, das nicht richtig funktioniert
- Direkte DUnitX-Unterstützung ohne moderne IDE-Integration

Habe ich etwas vergessen? Wahrscheinlich nicht, wenn selbst Embarcadero die überarbeitet Startseite mehrfach in der Feature-Matrix nennt. Offenbar mussten sie krampfhaft nach nennenswerten Einträgen suchen, damit die Liste nicht so leer aussieht. Insgesamt wirkt auch die neueste Version von Delphi völlig veraltet und fehlerhaft. Wer mal mit Visual Studio oder NetBeans ein Projekt C# oder Java umgesetzt hat, wird wissen, in welchen Bereichen Delphi in Puncto IDE und Sprachfeatures hinterher hinkt.

Mir kommt es ehrlich so vor als ob es Embarcadero völlig egal ist, wie oft das Produkt noch verkauft wird. Den Bestandskunden wird das Geld aus der Tasche gezogen ohne dass es dafür eine echte Gegenleistung gibt. Über viele Jahre war ich ein Delphi-Enthusiast aber was Embarcadero veranstaltet, schreckt mich davor ab, irgendeinem meiner Kunden Delphi zu empfehlen. Mal ganz ehrlich: Selbst wenn die Professional-Version nur 200€ kosten würde, warum sollte ich Delphi XE8 gegenüber anderen IDEs vorziehen?

Zitat von Wosi:

Unter Delphi wird es sich dann wohl weiterhin wie in den neunziger Jahren anfühlen, wenn man mit Fremdbibliotheken arbeitet.

Wenn du mit neunziger Jahre meinst, dass man sich darauf recht gut verlassen kann, dass die Projekte auch gepflegt und für neuere Versionen angepasst werden, bin ich voll dafür.

Was nützt es mir, wenn ich zwar alles abrufen kann, aber wie bei Torry tausende Leichen drin habe, die schon seit X Versionen nicht mehr funktionieren. Oder wenn ich eine Komponente für XE9 downloaden kann, diese aber für XE10 plötzlich nicht mehr verfügbar ist, weil sie niemand dafür angepasst hat.
Weniger ist an der Stelle (finde ich) eindeutig mehr...

Zitat von Wosi:

Castalia wirkt reingeklatscht. [..] Die "Extract-Method"-Funktion produziert weiterhin Müll. Was bringt mir eine Prozedur mit einem Var-Parameter?

Da muss ich leider zustimmen. Nachdem ich es mittlerweile ausprobiert habe, ist es qualitativ leider nicht besser als das integrierte Refactoring, im Gegenteil, es funktioniert sogar noch schlechter. Ich dachte vorher nicht, dass das möglich sei...
In einem Projekt mit nicht einmal 29.000 Zeilen...
"Castalia exceeded its allowed memory threshold for parse trees"
"No current file found. Prepare for an EIndexOutOfBounds error."
Und dann Schutzverletzung...

Aber schlimmer noch:
Im Gegensatz zum internen Refactoring wurde das Refactoring hier versucht trotzdem durchzuziehen. Teilweise werden Extraktionsmethoden erstellt, bei denen konstante Werte als var-Parameter weitergegeben werden, teilweise wird der extrahierte Code einfach ein paar Zeilen darüber in die gleiche Methode an zufälliger Stelle eingefügt (z.B. nach dem Semikolon einer SQL-Anweisung innerhalb eines Strings!!) und die Parameter blieben leer, ...

Beim "Surround with..." wird Code erzeugt, bei dem die Einrückung nicht stimmt, manchmal lässt sich die Aktion auch nicht per Strg + Z rückgängig machen, teilweise wird ein end zu wenig eingefügt, ...

Beim Methode umbenennen:
"No current file found. Prepare for an EIndexOutOfBounds error."
Schutzverletzung...

Ich dachte dann das läge eventuell am Projekt, aber das gleiche passiert bei zwei anderen ähnlich großen Projekten auch. Sorry, aber ich habe immer wieder Positives zu Castalia gehört. Das kann ich leider absolut nicht nachvollziehen, ich bin nur froh, dass wir dafür vor der Integration in Delphi kein Geld ausgegeben haben.

Man nehme ein Manifest, dass die Delphi-Version angibt (dann fliegen bei neuen Versionen automatisch die nicht gepflegten Komponenten in der Auswahl raus), dann einen Download-Counter und auch gerne noch ein Sterne-System. Und fertig ist ein System, dass sich selbst halbwegs aktuell hält, einen Indikator für Qualität hat und trotzdem mit Fremdpackages bestückt werden kann.

Bei PHP gibt es nur noch Composer / Packagist. Wenn was nicht auf der Plattform vorhanden ist, wird es schlicht nicht mehr verwendet. Da kann eine neue Bibliothek noch so gut sein. Im Frontend-Bereich läuft alles über Bower. Bei Node ist npm ein absolutes Muss.